Вход на сайт

Просмотр новости

Найдите то, что Вас интересует

GitHub Outage

Дата публикации: 28-08-2026 18:47:20

Vlad Fedorov (Hacker News): On August 17, GitHub experienced an outage that lasted 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations around the world. […] Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their […]

Основное содержимое страницы с новостью.

Vlad Fedorov (Hacker News):

On August 17, GitHub experienced an outage that lasted 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations around the world.

[…]

Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity. Since April, monthly commits have grown from 1.4 billion to 2.9 billion. That growth explains the pressure on our systems, but it does not excuse these outages.

[…]

As part of the reliability commitments we made earlier this year, we have focused on three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks. We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.

Alejandro Forero Cuervo:

This is the wrong way to think about this because there’s no such thing as infinite capacity. A large distributed system will be simultaneously mostly idle and (in some subcomponents) overloaded. The root cause is not “a component didn’t have enough capacity (because of auto scaling failures)”, but rather “this complex system collapses (rather than degrade gracefully) when demand exceeds capacity”.

When components reach capacity limits, the excess traffic of the lowest priority should be rejected. Rejected traffic should not be retried — in fact, not only should clients not retry these errors, these errors should cause client-side throttling. Traffic isolation should be applied — if the cause of the overload is a single client/customer system, no other system should be affected.

Nearly a decade ago I wrote about some of the techniques we applied at Google to implement these protections. Most other large internet services have since copied them, afaik.

Previously:

Craft GitHub Microsoft Azure Outage Programming Web

6 Comments





Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1GitHub’s Latest Service Disruptions Reveal Persistent Reliability Strain016.0207-10-2026
2Disruption with GitHub Billing012.3227-08-2026
3Disruption with some GitHub services011.3926-08-2026
4Ausfall bei GitHub: Actions, Pages und Abrechnung gestört010.405-10-2026
5Disruption with Copilot Code Review010.9704-09-2026
6Github authentication07.1615-05-2025
7В работе Рунета произошел масштабный сбой01008-10-2026
8Rendering huge pull requests in the GitHub Copilot app07.0623-09-2026
9Post Incident Report: Oct 6, 2026 - Delays in pipelines, workflows, UI data, and notifications012.3507-10-2026
10Twitter Shuts Down Nitter014.5126-08-2026

Классификация: Происшествия. Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 15.31. Источник: mjtsai.com.