By GitHub logged 13 separate incidents in the first 17 days of August 2026. The worst one — on August 17, lasting 7 hours and 47 minutes — took down Actions, authentication, Copilot, APIs, and pull requests simultaneously. If your team spent that Monday unable to deploy, authenticate, or even open a PR, you were not alone. And if you are still treating GitHub Actions as infrastructure you can rely on without a fallback, you are setting up for the same day again.
Two Products, Two Reliability Tiers
Here is the number that matters: GitHub Actions sat at 99.33% uptime over the last 90 days. Git operations — push, pull, clone — held at 99.99% over the same period. That gap sounds small. It is not.
A three-nines SLA (99.9%) permits roughly 2.2 hours of downtime per quarter. The August 17 outage alone lasted nearly 8 hours — consuming more than three times a full quarter’s allowable downtime in a single afternoon. Over 90 days, Actions accumulated about 14.5 hours of disruption. Git operations? Closer to 13 minutes.
| Service | 90-Day Uptime | Downtime (90 Days) |
|---|---|---|
| GitHub Actions | 99.33% | ~14.5 hours |
| Git Operations | 99.99% | ~13 minutes |
These are not the same product. Git is a simple, well-understood protocol that GitHub distributes reliably. Actions is a complex distributed compute platform that runs on shared infrastructure, couples with authentication services, and integrates directly with Copilot. The more GitHub has expanded its product surface area, the bigger the blast radius when something fails.
The Outage Was Interesting Before It Was Frustrating
GitHub’s official post-mortem revealed a cascading failure worth understanding. An Istio sidecar pod hit its concurrency limit. The autoscaling policy that should have caught this was misconfigured — it monitored the host service’s metrics, not the sidecar’s own limits. Four HAProxy nodes then hit their flow limits, degrading the authentication path and taking down everything that required a token.
Then it escalated. A latent retry bug in VS Code kicked in when the Copilot Token Service started returning errors. VS Code retried aggressively, amplifying traffic from roughly 7,000–9,000 requests per second to 70,000–100,000 requests per second. Recovery became self-defeating: every attempt to come back online was met with another wave of retries. The Register’s technical breakdown of this retry storm is worth reading for the architecture lessons alone.
The takeaway is not that GitHub made a careless mistake. It is that modern software stacks have become so deeply layered — your IDE, your CI, your code host, your AI assistant — that a misconfigured policy in one place can cascade across all of them simultaneously.
Enterprise Teams Have a Compounding Problem
For organizations using GitHub with SAML SSO, the August 17 outage was doubly disruptive. When authentication fails, it does not just take down Actions — it eliminates the ability to authenticate at all. SAML, OIDC, and SCIM provisioning went dark alongside the CI/CD layer. Teams running SSO-gated pipelines lost both the gate and the pipeline simultaneously.
There is also a compliance risk that is easy to overlook. Many engineering organizations have documentation that references “GitHub” by name — in SOC 2 controls, in change management policies, in audit trails. When your controls name a specific vendor, you have baked a hidden dependency into your compliance posture. Auditors verify that your controls are active, not that GitHub’s status page is green. The outage ends in hours; the audit finding does not.
What Actually Helps (and What Does Not)
The instinct after an outage like this is to add self-hosted runners. That instinct is wrong. Self-hosted runners still depend on GitHub authentication to register and receive jobs. If GitHub’s auth layer is down — as it was on August 17 — your runners are idle regardless of where they are physically running.
Real resilience looks different. As noted in the post-outage reliability analysis, organizations should treat Actions as a dependency requiring a fallback — not a fallback itself. Practical steps:
- Mirror repositories to GitLab or Bitbucket so builds are not anchored to a single endpoint
- Write portable pipelines — minimize GitHub-specific action syntax in favor of shell scripts and containers that run anywhere
- Evaluate Buildkite or GitLab CI as a secondary CI provider; both support self-hosted agents with a managed control plane independent of GitHub’s authentication
- Audit your compliance documents — anywhere they reference “GitHub,” ask whether the control requires GitHub specifically or just peer review and version control
GitHub Will Fix the Proximate Causes
GitHub has committed to adjusting Istio autoscaling at the sidecar level, patching the VS Code retry behavior, improving load balancer monitoring, and building better regional failover. These are real fixes that reduce the likelihood of this exact cascade repeating.
But the structural issue — that Actions is a highly coupled, rapidly expanding SaaS product being operated as if it were durable infrastructure — will not be resolved by patching one misconfigured policy. GitHub’s reliability model has not kept pace with its product surface area expansion. Thirteen incidents in 17 days suggest that is a trend, not a fluke. Plan accordingly.
