GitHub’s Latest Outage Should Have You Rethink Where You Store Code
Last Monday (August 17), quite a few companies felt a substantial disruption to their workflows: GitHub went down for roughly 7 hours and 47 minutes, and it wasn't a partial hiccup. The outage hit github.com itself, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot — basically every layer a modern dev workflow leans on.
What actually happened
GitHub's own postmortem and outside reporting paint a more specific picture than "we got too popular." The trigger was a network component called an Istio sidecar hitting its concurrency limit at their Central US facility. Normally, autoscaling should have kicked in and added capacity, but the autoscaling policy was misconfigured to watch the wrong metric (the host service, instead of the sidecar's actual concurrency limit), so extra capacity never arrived when it was needed.
Things got worse from there. Retry behavior across services piled on more traffic during the recovery window, and a previously unknown bug in VS Code's retry logic amplified Copilot token traffic by roughly 10x, which is why Copilot took the longest of any service to fully recover (full restoration wasn't until about 9 PM UTC, hours after most other services had come back).
GitHub does note that this comes against a backdrop of real growth — monthly commits have nearly doubled since April, and pull requests, repos, and Actions usage are all climbing sharply. Whether that's driven by AI coding agents specifically isn't something GitHub explicitly says, but it's a reasonable thing to wonder about given how much "agentic" development has picked up this year.
Part of a pattern?
This was GitHub's second significant incident this month alone, following an Actions failure on August 6, and it comes on the heels of availability issues they'd already been publicly addressing back in March and April. For a platform that's historically been one of the most trusted places to store, build, and ship code, that's a rough stretch.
It also brought back to mind something Mitchell Hashimoto (HashiCorp's co-founder) wrote back in April, when he announced that his terminal emulator project, Ghostty, would be leaving GitHub after an unrelated outage cost him hours of PR review time. He'd been on GitHub since 2008 and described it as somewhere he'd been happiest, but said the constant disruptions had made it "not a fun place" to get work done anymore. That post wasn't about Monday's outage — it predates it by months — but it's hard not to read it as an early warning sign of exactly this kind of week.
And the timing isn't lost on the market, either: Cursor just launched Origin, its own code-hosting platform designed to sit alongside GitHub — import your repos, move code between the two — rather than replace it outright. It's not a direct GitHub killer, but it's one more sign that reliability is becoming a real competitive axis in this space.
I don't think GitHub is going anywhere. But between the repeated outages this year and credible alternatives starting to show up, I understand why more teams are asking whether an all-eggs-in-one-basket approach still makes sense.
Sources: https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/, https://www.computing.co.uk/news/2026/security/github-outage-exposes-flaws-in-autoscaling-and-retry-systems, https://mitchellh.com/writing/ghostty-leaving-github
