On August 17, 2026, GitHub went through a rough day. For nearly eight hours, large parts of the platform struggled. API requests, Actions, pull requests, Issues, webhooks, and Copilot all felt the impact. Error rates hit around 20% on web and API traffic. Archive and raw content downloads failed about half the time.
The official status page eventually said engineers had identified a problematic component and applied fixes. Later updates mentioned something more interesting: they partially disabled authentication-token retries because those retries were making the problem worse.
That detail is worth sitting with.
How retries turn a problem into a cascade
Most systems retry failed requests. It is a reasonable default. When an authentication call times out or returns an error, the client tries again. Under normal conditions this improves reliability.
Under stress it can do the opposite.
Here is the basic loop:
- Something degrades the authentication service.
- Clients start receiving failures or slow responses.
- Those clients retry.
- The extra traffic increases load on the already struggling service.
- More requests fail, which triggers more retries.
The system enters a feedback loop. The retries that were meant to help become the main source of pressure. Engineers at GitHub observed this happening and chose to limit the retries so the authentication layer could recover.
This pattern is sometimes called a retry storm or a metastable failure. Once the system is in that state, removing the original trigger is not always enough. The amplified traffic keeps the service saturated.
Different approaches to the same problem
Microsoft and Google have spent years designing authentication systems that try to avoid this exact trap.
Microsoft Entra ID includes a backup authentication service that runs on separate infrastructure. When the primary system is degraded, the backup can continue serving tokens for existing sessions. Their client libraries (MSAL) are also written to respect rate limits and avoid aggressive retry loops. Continuous Access Evaluation lets them issue longer-lived tokens while still supporting near real-time revocation.
Google tends to favor short-lived access tokens paired with disciplined client behavior. Official client libraries use exponential backoff with jitter and only retry certain classes of transient errors. Permanent failures are not retried endlessly. Token validation often relies on cached public keys, which reduces live dependency on the identity service.
These systems were built with planetary scale and known failure modes in mind. Authentication is treated as critical infrastructure that needs its own isolation and fallback paths.
GitHub's architecture has historically been more tightly coupled. When authentication slows down, many other services feel it quickly. The recent outage made that coupling visible.
Why GitHub does not simply switch to Microsoft's identity stack
GitHub is owned by Microsoft, so the question comes up often: why not just use Entra ID and MSAL?
There are practical reasons.
GitHub was kept relatively independent after the acquisition. That independence mattered to the developer community. Moving the entire identity system onto Entra ID would have changed the product in ways that go beyond technical convenience.
The user models are also different. GitHub supports personal accounts, open source projects, and enterprises. Entra ID is optimized for organizational identity. Enterprises can already choose tighter integration through SAML, SCIM, and Enterprise Managed Users. Making that the only path would break the model that most individual developers use.
MSAL itself is a client library. It helps applications acquire tokens from Entra ID. It does not replace the need for GitHub to issue, validate, and manage its own tokens for Git operations, GitHub Apps, Actions, and the API. Solving the retry cascade requires changes inside GitHub's own authentication services, not just a different client library.
What this leaves us with
The outage was disruptive. It also made a common systems problem concrete. Retries are useful until they are not. When the thing you are retrying is the authentication layer that everything else depends on, the cost of those retries can rise quickly.
Good authentication systems plan for this. They limit amplification, provide fallback paths, and treat token services as critical infrastructure rather than just another internal dependency.
GitHub will likely continue improving its own stack. The rest of us can take the simpler lesson: when designing retry logic, ask what happens when the dependency is already under pressure. The answer is often more important than the happy path.
