1 month, 5 outages: Databases are under massive strain at GitHub

GitHub suffered five outages in August 2026, two lasting more than nine hours, according to a post-mortem and incident reports from the Microsoft-owned code host, which attributed the failures to routine events like pod deployments and traffic spikes hitting infrastructure that is close to capacity. GitHub SVP of software engineering Jakub Oleksy said in the September 9 update that the company still needs "more durable capacity and isolation," and GitHub plans to move database primaries to Azure, migrate more services and traffic to Azure, improve shared-database health, add capacity-management and auto-scaling automation, and extend dependency-failure handling over the next month. Short-term additions have cut peak cache CPU utilization for GitHub Actions from 98% to 80%, a gain GitHub expects to last only three months as demand surges.

The world’s largest code host, GitHub, suffered five outages in August, two of which lasted over nine hours. They ultimately had one common thread: Too many people and too many agents straining the seams of its creaking infrastructure. As a new post-mortem https://github.blog/news-insights/company-news/github-availability-report-august-2026/?ref=thestack.technology /set of incident reports from the Microsoft-owned company shows, all were triggered by what could be seen as “everyday” occurrences: a routine pod deployment, a spike in traffic, or a standard burst of incoming events. But because GitHub’s infrastructure is, as it has previously transparently disclosed https://www.thestack.technology/github-throttles-struggling-copilot-over-intensifying-usage/ , dangerously close to capacity, these minor fluctuations blew things up. Moving MySQL database primaries to Azure is a big part of its efforts GitHub said. Last month the company admitted that it was moving services to other clouds too. GitHub CTO: We’re going multicloud amid AI stress https://www.thestack.technology/github-cto-were-going-multicloud-amid-ai-stress/ GitHub CTO: We’re going multicloud amid AI stress The company has made some short-term changes: Additional production capacity has trimmed peak cache CPU utilisation for GitHub Actions from a worrying 98% to 80% – a win it expects to last just three months as demand continues to surge. But as GitHub's SVP, software engineering, Jakub Oleksy admitted in the September 9 update, it still needs "more durable capacity and isolation." GitHub said over the next month it will be moving “database primaries, continuing to migrate services and corresponding traffic to Azure, chipping away at database health particularly on shared-databases, adding more automation around capacity management and auto-scaling, and extending dependency-failure handling…” The company’s recent updates reveal that high-volume services Actions job assignment, Copilot policy checks, pull request tracking largely remain bound to shared relational database clusters; as a result high query demand from a single subsystem rapidly exhausts connection pools and worker thread capacity. Arguably predictably, attempting database failovers under peak pressure rarely provides instant remediation for GitHub: The post-mortems show replication lag, partition backlogs, or slow failover configurations, often forcing teams to manually shed traffic at the edge or throttle inbound webhooks to allow recovery. As Peter Zaitsev, Co-Founder at database management firm Percona commented: “Moving the queries to a different system than the production database, or to replica database environments as GitHub says it is doing , is one of the classic approaches to load management. It means your production systems do not face issues when you run analytics or queries at the same time as processing transactions. He added: “The ‘query hygiene,’ as the GitHub team puts it, is also important and often overlooked when databases scale up. As your applications change, you often have queries that are no longer needed or that fetch unneeded data. The query keeps on fetching the data it was written for at the time, rather than what you want now. “From the Github report, we can see how significant the impact can be when you get to this level of scale. Auditing database performance and query response times is something that traditional DBAs would carry out, but those areas can be forgotten when developers or more generalist staff have to take on responsibility for database instances… Our State of Open Source Database Management report https://www.percona.com/resource/state-of-open-source-db-management/?ref=thestack.technology this week found that cloud costs are the biggest issue that companies face around cost of ownership for databases, so making those queries run more efficiently doesn’t just make them run faster. It cuts the cost of your infrastructure, and reduces spend over time.” August's GitHub outages in brief. August 06 10h 42m : A routine deployment reduced pod count. This slight reduction exhausted all available headroom. As a result, service-mesh sidecars suffered CPU throttling and out-of-memory restarts, cascading into cache, DNS, and API errors. August 17 7h 35m : A surge in traffic pushed load balancers past their limits https://www.thestack.technology/github-down-in-worldwide-multihour-outage-again/ . A service-mesh sidecar hit its concurrency limit and failed to scale. Requests queued up, load-balancer nodes exhausted their network flow limits, a shared gateway authentication path creaked under the strain; issues, PRs, and APIs fell over. August 20 9h 54m : A burst of incoming events arrived during a daily traffic peak. A cloud shared DBaaS GitHub doesn’t name it relied upon by GitHub Actions fell over. Engineers began a regional failover, but a storage configuration on the database made the region slow to move so task-status updates kept backing up. August 26 2h 50m : Again, too much activity strained GitHub’s infrastructure; again with a “database overloaded” – as a result, the “internal service that turns incoming events into runner assignments could not keep up, so actions runs failed to start and began queuing well past their normal start time,” GitHub said. August 27 2h 8m duration : As with August 20, this was a third-party failure that affected users of the Kimi K3 LLM, which “is served by an upstream model provider” that GitHub said had a “serving degradation”. Other models and “requests made with the Auto setting, which routed to a different model were not affected.”