On August 17, GitHub was unreachable for seven hours and forty-seven minutes. Authentication failed. Pull requests, issues, and GitHub Actions stopped working. So did Copilot. If your team pushes code, deploys software, or runs automated builds through GitHub, that Sunday cost you a working day whether you noticed it happening or not.

What makes this outage worth your attention isn't the length. Cloud services go down; that's not news. What's worth sitting with is why it went down, because the answer isn't the one most people assume.

It wasn't a bug. It was capacity.

GitHub's own postmortem is unusually direct about the cause. In a statement published this week, CTO Vladimir Fedorov wrote that traffic reached a new peak and "a critical infrastructure component in our Central US data center failed to scale with it." The resulting pressure spread through the system, breaking authentication and taking down services well beyond the original bottleneck. Recovery took hours because engineers had to reroute traffic, isolate the affected systems, and bring services back online in stages, one piece at a time.

This was the second significant GitHub incident in August, following an Actions failure on August 6. Fedorov's explanation for the pattern is almost mundane: since April, monthly commits on the platform grew from 1.4 billion to 2.9 billion. That's not a hack, a misconfigured server, or a junior engineer's bad deploy. That's a company whose usage doubled faster than its infrastructure plan accounted for.

"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."

That line matters because it means the failure wasn't a fluke anyone could have caught with better testing. It was a forecasting problem at a company with thousands of engineers and a direct financial incentive to get this right.

You depend on GitHub even if you've never opened it

Most business owners have never logged into GitHub and never will. That doesn't mean they weren't affected on August 17.

If your website or software is built and maintained by a development team, there's a good chance their deploy pipeline runs through GitHub Actions. If a tool you use plugs into other services through integrations, some of those integrations likely depend on code hosted, built, or authenticated through GitHub somewhere in the chain. None of that shows up on an invoice or a dashboard you'd ever see. It just quietly stops working, and the first sign is usually your developer saying "we can't ship a fix right now" at the exact moment you need one.

This is the part that's easy to miss about running a business on modern software: your reliability is only as strong as the weakest vendor three layers removed from you. GitHub is about as well-resourced as that kind of vendor gets, and it still went dark for nearly eight hours twice in one month.

What to actually ask your host or dev partner

The useful response to an outage like this isn't panic about GitHub specifically. It's a short list of questions worth asking whoever manages your website, software, or hosting, because the answers tell you how exposed you actually are.

Ask what happens to your deploy pipeline if a third-party service goes down. A team that has thought about this has a fallback, even a manual one. A team that hasn't will discover the gap live, during the outage, at the worst possible time.

Ask how you'd find out if your site or app went down outside business hours. Uptime monitoring that pages a human is cheap and unglamorous, and a lot of small business sites don't have it. If the first person to notice your site is offline is a customer trying to buy something, that's not a monitoring gap, it's a revenue gap.

Ask what single points of failure exist in your stack. Every business running on modern software has some: a hosting provider, a payment processor, an email service, a CMS. The goal isn't zero dependencies, which is impossible. It's knowing which ones would actually hurt if they failed, and having at least a rough plan for the ones that would.

Reliability is a practice, not a purchase

It's tempting to read a story about an outage at a company GitHub's size and conclude the lesson doesn't apply to a smaller operation. The opposite is closer to true. GitHub can absorb a bad day: it has the engineering depth to publish a detailed postmortem, add millions of dollars in capacity, and move more load onto Azure within months. A small business usually doesn't get that kind of runway. One bad outage during a launch, a sale, or a client deadline can do damage that takes a lot longer than eight hours to undo.

The businesses that come through incidents like this fine aren't the ones with zero dependencies. They're the ones whose maintenance and support actually includes watching for problems before a customer reports them, and whose developers have thought through what happens when a service they rely on, whether it's GitHub or any other integration, has a bad day. That's not a dramatic ask. It's the difference between an outage being a story you read about and an outage being something that happens to you.

If it's been a while since anyone looked at what your maintenance plan actually covers, this is a reasonable week to ask.