Red Squares hiển thị sự cố GitHub như các đóng góp
(red-squares.cian.lol)- Red Squares nhại lại biểu đồ đóng góp commit của GitHub, hiển thị sự cố của nền tảng GitHub.com bằng các ô màu đỏ thay vì ô màu xanh lá
- Mỗi ô đỏ biểu thị một ngày GitHub gặp sự cố, và màu càng đậm thì ngày đó sự cố kéo dài càng lâu
- Trong 1 năm gần đây, tổng thời gian GitHub bị downtime được thống kê là 32,5 ngày
- Số ngày có ít nhất 1 incident là 167 ngày
- Ngày tệ nhất là Thứ Năm, 30 tháng 4 năm 2026, với thời gian downtime lên tới 1,0 ngày
1 bình luận
Ý kiến trên Hacker News
Mỗi khi có một trang meme vibe coding kiểu này xuất hiện thì lại có vô số bình luận nói rằng nguyên nhân thực sự không phải do tải, mà là vì đội GitHub, tech stack, Microsoft và Azure quá tệ
So sánh trang trạng thái GitHub công khai với trang Enterprise Cloud thì số liệu phía Enterprise tốt hơn hẳn, và cá nhân tôi cũng không nhớ lần gần nhất gặp sự cố nghiêm trọng đến mức không thể làm việc là khi nào
Nếu vấn đề không liên quan đến tải, thì theo tôi sản phẩm Enterprise cũng phải cho thấy cùng mức vấn đề về uptime
Đặc biệt với một công ty có nhiều tài nguyên hơn cả nhiều quốc gia và có đội ngũ kỹ thuật hàng đầu thế giới, thì việc chỉ trích hệ thống là hoàn toàn hợp lý
Tech stack của GitHub thực sự không tốt, và họ đã phòng thủ nó khá kiêu ngạo trong thời gian dài
Azure là một nền tảng tệ hại nhưng đang bị ép xuống các đội, và tôi cũng từng thấy thái độ phòng thủ về việc chọn cơ sở dữ liệu quan hệ hay việc viết lại frontend
Không thể giữ cho site chạy ổn định mà lại đi viết lại UI và ép triển khai công cụ AI thì chỉ là lãng phí thời gian
Đây không phải là công kích kỹ sư cá nhân, mà là chỉ trích lựa chọn của ban lãnh đạo khi một hệ thống đã gần như độc quyền nhờ hiệu ứng mạng lại ưu tiên tính năng mới hay làm hài lòng chủ sở hữu hơn là sản phẩm cốt lõi
Vì trang trạng thái có thể bị dùng làm bằng chứng bất lợi cho công ty, nên bản thân việc so sánh đó cũng không có nhiều ý nghĩa
Trên thực tế nhiều khi là sự cố nhưng trong ngôn ngữ marketing lại gọi là “suy giảm hiệu năng”, và các trang trạng thái vận hành độc lập hữu ích hơn nhiều
Không phải ngày nào cũng vậy, nhưng tôi gần như không nhớ nổi một tuần nào ở công ty mà không phải tìm cách lách qua sự cố
Trong đa số trường hợp vẫn có thể tiếp tục “làm việc”, nhưng những việc đáng lẽ đã build hoặc deploy xong trong cùng khoảng thời gian nếu không có sự cố lại bị chậm, nên cá nhân tôi thấy mình bị ảnh hưởng ít nhất 1 lần mỗi tuần
Nếu không thì ít nhất nên dán cảnh báo to đùng ở trên là “chỉ dùng cho mục đích sở thích”
Có thể trả lời thread cũ nhưng không thể tạo thread mới, và việc này cũng đã lên trang trạng thái
Tôi không hiểu sao chuyện như vậy lại được đưa ra, và cũng khó hiểu vì sao nó kéo dài suốt một tiếng rồi
Lại còn bảo cần thêm 3–4 tiếng nữa mới sửa xong, thật chu đáo
Đổ cả chuyện suy giảm hiệu năng của các model bên ngoài như Gemini 2.5 Pro, Grok Code Fast 1 in Copilot hay Claude Opus 4 cho GitHub thì có vẻ không công bằng
Tôi nghĩ đây là loại vấn đề mà GitHub cũng chẳng thể làm gì được
Mức độ nghiêm trọng bị xóa nhòa, rồi tất cả bị rút gọn thành “GitHub bị sự cố” hoặc thành biểu đồ uptime
Tôi cũng không hài lòng với các sự cố lớn gần đây của GitHub, nhưng tôi không thích việc ngày càng nhiều trang câu chú ý và bài đăng mạng xã hội làm mờ ranh giới giữa suy giảm nhỏ của một dịch vụ với sự cố toàn site để trông kịch tính hơn và kiếm đề xuất, lượt thích, karma và sự chú ý
Có vẻ như họ chỉ muốn làm cho biểu đồ đỏ nhất có thể
Chúng tôi vận hành một dịch vụ nhỏ hơn GitHub rất nhiều, nhưng vẫn chuẩn bị đường thay thế với nhiều nhà cung cấp và nhiều model khác nhau
Cuối tuần vẫn là miền biên cương chưa được khai phá
Vẫn còn chỗ để mở rộng
Sự cố xuất hiện trong 62% số ngày thường và 11% số ngày cuối tuần, còn Claude cũng tương tự với 92.5% ngày thường và 97.8% cuối tuần
Từ thứ Ba đến thứ Năm là vùng nguy hiểm, còn Chủ nhật thì trông như hẳn một dịch vụ khác
https://www.aakash.io/tech-chase/github-and-claude-are-down-...
Trước hết tôi còn nghi ngờ biểu đồ này có chính xác hay không
Nó ghi “170 ngày có ít nhất một sự cố · ngày tệ nhất là thứ Năm 2025-11-20, 1.1 ngày”, mà tôi không hiểu tổng trong một ngày lại có thể là 1.1 ngày bằng cách nào
Kể cả khi rê chuột lên ngày đó cũng không thấy cách tính nội bộ, còn một mục đơn lẻ thì hiện là 1.3 giờ
Ngày 2025-11-19 có một mục sự cố 1.3 ngày nhưng tổng lại hiển thị là 8.1 giờ
Vào ngày đó nó hiển thị 24 giờ suy giảm nhẹ
Có vẻ trang này đang cộng downtime của tất cả dịch vụ trong một ngày, và nếu vậy thì ngày tệ nhất có thể lên tới 10 ngày downtime nếu cộng downtime trong ngày của từng danh mục chính
1: https://mrshu.github.io/github-statuses/
Tôi chưa xác minh hôm đó có thực sự downtime hay không, nhưng nếu giả sử các con số là đúng thì 7.8 giờ cộng thêm 1 ngày sẽ xấp xỉ 1.3 ngày
Chênh lệch giữa trang trạng thái chính thức [0] và trang trạng thái bên thứ ba [1] là quá lớn
Nếu tình hình sử dụng sản phẩm thực tế lại khác đến vậy thì tôi thấy khó hiểu các điều khoản thỏa thuận mức dịch vụ làm sao lại hợp pháp
Tôi thích GitHub và dịch vụ này, nhưng mỗi lần sản phẩm thực tế đã hỏng mà trang trạng thái vẫn xanh lè là trong lòng tôi lại sôi lên
[0] https://www.githubstatus.com/
[1] https://mrshu.github.io/github-statuses/
Ở nơi tôi làm gần đây, chúng tôi gặp nhiều sự cố GitHub không hề xuất hiện trên trang trạng thái chính thức, và tôi đã lưu log lại bằng tìm kiếm trong Slack
Sau đó phía kinh doanh tranh cãi với quản lý tài khoản GitHub và cuối cùng nhận được vài trăm USD credit
Nhưng rồi họ lại than rằng vài trăm USD credit đó chẳng đáng gì so với thời gian đã bỏ ra, nên uptime thấp của GitHub vẫn tiếp diễn và chẳng có gì xảy ra cả
Trong khi đó trang bên thứ ba lại coi cả sự cố hay vấn đề của chỉ một model cụ thể là vấn đề của GitHub, nên có thể khác với trải nghiệm sử dụng thực tế
Cuối tuần thì sự cố ít hơn hẳn
Đằng nào lúc đó tôi cũng không định làm việc, nên quá hoàn hảo
Ý tưởng này đã có từ trước rồi
Tôi đã làm cái này vào tháng 1 để thử tách uptime theo từng hạng mục sự cố
https://isgithubcooked.com
Việc gần như không có downtime vào cuối tuần nhìn khá giống biểu đồ đóng góp, nên thấy buồn cười