GitHub Actions Sập 6 Giờ: Sự Cố Lớn Thứ Hai Và Hồi Chuông Cảnh Tỉnh

Ngày 6/8/2026, GitHub Actions — nền tảng CI/CD của hàng triệu developer — đã sập trong hơn 6 giờ liên tục. Đây là sự cố lớn thứ hai được ghi nhận trong lịch sử nền tảng. Và nó không đến một mình.

Sự cố bắt đầu lúc 15:22 UTC và đến 21:30 UTC vẫn chưa được giải quyết hoàn toàn. Không chỉ Actions bị ảnh hưởng — GitHub Pages, Copilot code review, Copilot coding agent, và GitHub Enterprise Importer đều chịu tác động dây chuyền. Webhook bị giới hạn tốc độ xử lý xuống chỉ còn ~15% công suất, đồng nghĩa với việc phần lớn push và pull request không kích hoạt được workflow.

Chuyện Gì Đã Xảy Ra?

Theo timeline từ GitHub Status, sự cố trải qua nhiều giai đoạn:

Thời gian (UTC)	Diễn biến
15:22	Báo cáo đầu tiên: Actions "degraded performance"
15:41	Hạ cấp xuống "degraded availability"
15:45	Workflow không khởi động hoặc fail giữa chừng, REST API trả lỗi, rate limit bất thường
16:27	Pages bắt đầu bị ảnh hưởng
17:02	Copilot code review, Copilot coding agent, GitHub Enterprise Importer gặp lỗi
17:40	Nhiều biện pháp khắc phục được triển khai nhưng chưa giải quyết hoàn toàn
18:46	Jobs vẫn fail hoặc delay, self-hosted runners gặp lỗi khi đăng ký
20:34	Chỉ ~15% webhook hoạt động, ~65% job thành công (từ đáy 30-40%)
21:30	Runners nhận jobs không còn hợp lệ; đang deploy fix; GitHub Enterprise Importer bị pause

Điểm đáng chú ý: sự cố không chỉ ảnh hưởng đến GitHub-hosted runners mà còn cả self-hosted runners — những runner tự quản lý mà nhiều team đầu tư để tránh phụ thuộc vào hạ tầng của GitHub.

Không Phải Lần Đầu, Và Có Lẽ Không Phải Lần Cuối

Nếu chỉ là một sự cố đơn lẻ, bài viết này đã kết thúc ở đây. Nhưng con số thống kê mới là điều đáng báo động:

Tháng 7/2026: 26 sự cố
Tháng 6/2026: 23 sự cố
Tháng 5/2026: 23 sự cố
Tháng 4/2026: 26 sự cố
6 ngày đầu tháng 8/2026: 6 sự cố

Theo Pingoru, chỉ riêng GitHub Actions đã có 24 sự cố kể từ tháng 3/2026, tổng cộng 49 giờ downtime. Một sự cố tương tự đã xảy ra chỉ 8 ngày trước — ngày 29/7, khi Actions REST API timeout hàng loạt.

Mitchell Hashimoto, tác giả của Ghostty, đã công khai tuyên bố rằng GitHub "không còn đủ ổn định để host các dự án nghiêm túc" — một phát biểu nặng ký từ một trong những developer được kính trọng nhất trong cộng đồng open source.

Nguyên Nhân: AI Đang Gây Áp Lực Lên Hạ Tầng GitHub?

GitHub đã chỉ ra một phần nguyên nhân: sự bùng nổ của AI đang tạo áp lực khổng lồ lên hạ tầng. Copilot coding agent — vốn cần tài nguyên compute lớn để chạy các tác vụ agentic — đang cạnh tranh trực tiếp với GitHub Actions về mặt hạ tầng. Khi cả hai chạy trên cùng một nền tảng, một bên tăng trưởng đột biến có thể kéo theo bên kia.

Đây không phải là vấn đề mới. Tháng 5/2026, Microsoft đã phải nhờ AWS "giải cứu" GitHub vì hạ tầng AI quá tải. Rõ ràng, bài toán scaling cho AI workload đang là thách thức mà ngay cả Microsoft — với toàn bộ Azure phía sau — cũng chưa giải quyết được triệt để.

Nhưng đổ lỗi hoàn toàn cho AI là chưa đủ. Tần suất sự cố dày đặc trong 5 tháng liên tiếp cho thấy vấn đề mang tính hệ thống, không phải nhất thời. Một nền tảng xử lý CI/CD cho hàng triệu developer không thể có downtime trung bình ~8 giờ mỗi tháng (chỉ riêng Actions) mà không đánh mất niềm tin.

GitHub đã xin lỗi vào tháng 4 và hứa cải thiện. Tháng 6, SVP Jakub Oleksy cam kết những thay đổi "sẽ loại bỏ vĩnh viễn các failure mode." Nhìn vào số liệu sự cố sau tháng 6, những thay đổi đó hoặc chưa được triển khai, hoặc đã triển khai nhưng không đủ. Giải pháp thực sự có lẽ không nằm ở việc vá từng lỗi riêng lẻ, mà là tách biệt hạ tầng AI và CI/CD — để một bên tăng trưởng không kéo theo bên kia sập.

Điều Này Có Ý Nghĩa Gì Với Developer?

1. Đừng Đặt Tất Cả Trứng Vào Một Giỏ

Nếu toàn bộ pipeline CI/CD của bạn phụ thuộc vào GitHub Actions, một sự cố như hôm nay có thể chặn đứng hoàn toàn khả năng deploy. Đây là lúc cân nhắc multi-provider strategy:

GitHub Actions cho CI (test, lint, build)
GitLab CI hoặc Gitea Actions làm fallback CD
Trigger webhook đến cả hai provider cùng lúc

2. Self-Hosted Runner Không Phải Lá Bùa Hộ Mệnh

Sự cố lần này ảnh hưởng đến cả self-hosted runners — thứ mà nhiều team coi là giải pháp "thoát phụ thuộc" GitHub. Khi control plane của Actions gặp vấn đề, runner của bạn có khỏe đến mấy cũng không nhận được job.

3. Theo Dõi Status Một Cách Chủ Động

Subscribe GitHub Status RSS
Tích hợp alert từ GitHub Status vào Slack/Telegram của team
Thiết lập fallback trigger: khi webhook từ GitHub không đến trong X phút → kích hoạt pipeline dự phòng

4. Cân Nhắc GitOps Pull-Based

Thay vì push-based CI/CD (webhook từ GitHub kích hoạt pipeline), mô hình pull-based như Flux hoặc ArgoCD có thể giảm thiểu rủi ro. Khi GitHub webhook chết, pull-based controller vẫn tự polling và sync được.

Điều Cần Nhớ

GitHub Actions sập hơn 6 giờ — từ 15:22 đến 21:30 UTC ngày 6/8/2026, sự cố lớn thứ hai trong lịch sử nền tảng
Ảnh hưởng dây chuyền — GitHub Pages, Copilot code review, Copilot coding agent và GitHub Enterprise Importer đều bị tác động; webhook chỉ còn hoạt động ~15% công suất
Self-hosted runner cũng không thoát — khi control plane của Actions gặp sự cố, runner tự quản lý vẫn không nhận được job
Không phải lần đầu — đây là sự cố thứ 24 kể từ tháng 3/2026, tổng cộng 49 giờ downtime
AI là một phần nguyên nhân, nhưng không phải tất cả — Copilot coding agent cạnh tranh hạ tầng với Actions, nhưng tần suất sự cố dày đặc suốt 5 tháng cho thấy vấn đề mang tính hệ thống
Developer nên chuẩn bị phương án B — cân nhắc multi-provider strategy, theo dõi GitHub Status chủ động, và thử mô hình GitOps pull-based để giảm phụ thuộc vào webhook

GitHub Actions là công cụ tuyệt vời — khi nó hoạt động. Nhưng 49 giờ downtime trong 5 tháng, 26 sự cố mỗi tháng, và một sự cố kéo dài 6+ giờ ảnh hưởng đến cả Pages lẫn Copilot cho thấy nền tảng này đang gặp vấn đề về độ tin cậy ở mức hệ thống.

Developer không cần phải rời bỏ GitHub. Nhưng đã đến lúc nghiêm túc nghĩ về phương án B. Bởi vì lần tới khi bạn cần deploy gấp một hotfix lúc nửa đêm, câu "GitHub Actions đang down" không phải là câu trả lời mà team bạn muốn nghe.

Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.