GitHub revealed details of five incidents that affected the availability of its services during August 2026, including outages in GitHub Actions, delays in Copilot Cloud Agent results, and failures in requests to the Kimi K3 model. The company links the incidents to platform growth and narrow capacity margins, in addition to defects in autoscaling, retry policies, and recovery mechanisms.
GitHub says it is investing in improving its architecture and moving more services to Azure, while prioritizing availability, then capacity, then features. It also announced improvements in capacity monitoring, queue management, retry policies, and the resilience of core services.
Five Incidents with Different Causes
- August 6: The incident lasted 10 hours and 42 minutes after a routine deployment of an internal Actions service temporarily reduced capacity at one site. This caused services to become saturated and errors to spread to caching, DNS, and API interfaces, after which a defect in the job-assignment path slowed the recovery process. A large proportion of workflows failed or were delayed, and some events had to be restarted manually.
- August 17: The degradation lasted 7 hours and 35 minutes as load balancers in a data center reached peak capacity, while a sidecar component in the service mesh failed to scale despite reaching its concurrency limit. This caused delays and failures in the shared authentication path, extending the impact to Issues, Pull Requests, API interfaces, Actions, and Copilot. A retry defect also multiplied request traffic to an internal authentication endpoint.
- August 20: The incident lasted 9 hours and 54 minutes and affected the status and results of Copilot Cloud Agent tasks at least 54 organizations. A region at the cloud database provider that stores task states failed, and regional failover failed quickly because of a storage configuration, causing status updates to accumulate. The tasks themselves were not lost, but the display of results was delayed until processing was restored and the queue was drained.
- August 26: The degradation lasted 2 hours and 50 minutes when a batch of events pushed a shared database operating near its limit into saturation. This delayed the start of Actions jobs and affected dependent services such as Copilot Code Review and some GitHub Pages operations. GitHub had to gradually throttle incoming load because there was no automatic circuit breaker to activate protection when stress indicators appeared.
- August 27: The incident lasted 2 hours and 8 minutes and affected only requests directed to the Kimi K3 model within Copilot because of degradation at the external model provider. The failure rate for these requests exceeded half at the incident’s peak, while the other models and the Auto setting remained available.
What Changed in Practice?
The announced measures show that GitHub is treating the incidents as capacity, isolation, and recovery problems, rather than merely isolated deployment errors. It moved 33% of Actions jobs from a constrained production cluster to spare capacity, reducing peak cache processor utilization from 98% to 80% and adding, according to its estimate, roughly three months of headroom. Reads from services migrated to Azure also peaked at 60.4%, single-system reads at 64.3%, and Git reads at 54%.
At the database level, the first Azure production MySQL primary was brought online on August 11 without a noticeable impact on customer-observed write operations, and the pattern was repeated with two core databases on August 27. GitHub also removed about one million queries per second from copies of a legacy database, while other changes reduced traffic by 120,000 queries per second and approximately 59,000 seconds of wasted work per hour.
Why Does This Report Matter?
The incidents show that relying on horizontal scaling alone is insufficient when services share databases, authentication paths, or a single Actions infrastructure. Uncontrolled retries can also turn a partial degradation into broader load, while delays in switching between regions can cause states to accumulate even when the original tasks are not lost. The Azure plan, isolation measures, and load circuit breakers are still being implemented, so the report does not establish that the risks have been eliminated; rather, it shows where GitHub is focusing its upcoming work: migrating additional core databases, automating capacity management, and expanding its handling of dependency failures.