7 Hours, 47 Minutes: Inside GitHub’s August 17 Outage

7 Hours, 47 Minutes: Inside GitHub’s August 17 Outage

August 17.

For millions of developers, GitHub is infrastructure.

Code lives there. Deployments depend on it. CI/CD pipelines depend on it. Authentication, pull requests, Actions, APIs, and increasingly AI-assisted development all run through it.

So when GitHub starts failing, the problem doesn't stay inside GitHub.

It starts somewhere else.

And on August 17, the warning signs began appearing across the platform.

GitHub experienced a 7-hour-47-minute outage, affecting github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot for developers and organizations around the world.

What happened?

The incident wasn't a single service suddenly crashing.

Traffic had reached a level that exposed a capacity limitation in critical infrastructure running in GitHub's Central US data center.

One component couldn't scale quickly enough.

That created pressure on the systems around it.

And once a critical dependency starts struggling at GitHub's scale, the blast radius can grow surprisingly fast.

Authentication was affected. APIs degraded. Actions struggled. Other services began feeling the pressure.

The war room wasn't dealing with one broken service anymore.

They were dealing with a system behaving like a chain reaction.

The root cause

The deeper problem was capacity meeting architectural coupling.

GitHub has been experiencing rapid growth in workloads, with increasing repository activity, API usage, automation, and AI-driven development. That growth exposed limitations in parts of its infrastructure.

But there was another nasty twist.

During recovery, some Copilot traffic encountered errors that triggered a client-side retry loop.

Instead of failure producing less traffic, failures produced more traffic.

The platform was trying to recover while some clients were simultaneously asking it to try again.

That's the kind of feedback loop that turns a difficult incident into a prolonged one.

The impact

For nearly eight hours, developers around the world experienced failures or degradation across critical GitHub functionality.

That means more than a website being unavailable.

A failed GitHub API can break automation.

A degraded authentication system can prevent access.

A struggling Actions platform can stop deployments.

A failing pull-request workflow can interrupt the software delivery pipeline.

When your development platform becomes part of your infrastructure, its availability becomes an engineering dependency.

What DevOps engineers should learn

1. Capacity planning isn't “buy more servers.”

You need to understand where the actual bottleneck is—and whether dependent systems can scale with it.

2. Retries can become an outage multiplier.

Retries need backoff, limits, budgets, and preferably jitter. Otherwise, thousands of failing clients can turn recovery traffic into another incident.

3. Reduce blast radius.

A failure in one subsystem shouldn't automatically become a failure across authentication, CI/CD, APIs, and application traffic. Isolation matters.

4. Design recovery as carefully as failure.

The system recovering is still under pressure. Traffic restoration, retries, failover, and load redistribution can create a second failure if they're not controlled.

And perhaps the biggest lesson:

Production outages rarely have one villain.

They are usually a chain—

growth → capacity pressure → dependency failure → retries → more load → cascading impact.

That chain is where real DevOps engineering begins.

At InfraThrone, that's the kind of engineering muscle we want you to build—not just learning commands and tools, but learning how Kubernetes, cloud infrastructure, networking, CI/CD, application behavior, observability, and failure modes interact when everything starts going wrong.

Because the best time to experience a 2 AM production outage is before it's actually 2 AM.