On September 13, 2026, between 08:43 and 10:44 UTC, GitHub suffered a roughly two-hour "degraded availability" incident that touched about 28 services at once — Issues, Pull Requests, Actions, Codespaces, Pages, Notifications, Code Scanning, Git LFS, and new account signup among them. The trigger was unglamorous: an internal data-cleanup job began writing to a shared database cluster at 07:33 UTC, the same cluster that stores permission data GitHub reads on nearly every authenticated request. A safeguard meant to throttle that job was watching the wrong signal, and the resulting database saturation cascaded through overly long request timeouts and a retrying token-issuance service until GitHub restored full service at 10:44 UTC. It is the latest entry in a run of GitHub reliability incidents stretching back through August 2026, and it is a clean, well-documented case study in how a routine background job can take down a platform that tens of millions of developers depend on every day.
What happened, in order
According to GitHub's own incident record on githubstatus.com, the sequence ran roughly like this:
- 07:33 UTC — An internal data-cleanup job started writing to a shared database cluster that holds permission data.
- 08:43 UTC — GitHub's status page begins reflecting degraded availability across the affected services.
- Through the incident window — At peak, 8.8% of requests to create GitHub App installation access tokens failed. Token issuance for GitHub Actions workflows was affected too, hitting roughly 4% of workflow runs during the window. Creating issues through the web interface failed for about 96% of attempts, and new-account signups failed more than 90% of the time.
- 10:44 UTC — Services returned to normal.
The permission-data cluster sits on the critical path for authentication and authorization checks, so once it was under load, the blast radius extended far beyond whatever the cleanup job was nominally touching — which is exactly why services as unrelated as Pages and Git LFS showed up in the same incident.
Why the safeguard missed it
Site reliability engineer Lorin Hochstein, who writes the incident-analysis blog Surfing Complexity and has tracked GitHub's 2026 reliability issues closely, laid out the mechanics in a September 19 post. Per his read of the incident, three things compounded:
1. A monitoring blind spot. The rate-limiting safeguard on the cleanup job tracked a single health signal — how far the database's read replicas were lagging behind the primary. That signal stayed low the entire time, so the safeguard never engaged. The actual bottleneck was on the primary node itself, which was approaching its maximum connection limit — a dimension the safeguard wasn't watching at all.
2. Timeouts set too generously. Request handlers that depended on the permission database had long timeouts, so instead of failing fast when connections were unavailable, they queued and waited — holding resources and making the saturation worse rather than shedding load.
3. Retry amplification. A token-creation service kept retrying failed requests against the already-saturated database, adding load exactly when the system most needed relief, and delaying recovery even after the underlying cleanup job's impact should have tapered off.
None of these three is exotic. Each one, in isolation, is a known and generally well-understood failure mode. What made September 13 a two-hour, 28-service incident rather than a quiet blip was that all three were present in the same request path at once.
Not a one-off
This wasn't an isolated bad day. GitHub's own August 2026 availability report, published on its engineering blog, documents five separate incidents in that month alone, each with a distinct root cause: an Actions deployment causing capacity saturation on August 6 (10 hours 42 minutes), a traffic surge overwhelming load balancers on August 17 (7 hours 35 minutes, with "56.07% of front-door requests" failing or running slow), a cloud-database regional outage delaying Copilot agent status visibility on August 20, a database overload during a traffic peak blocking Actions run starts on August 26 ("more than one in five" run starts failing or badly delayed), and an upstream model-provider degradation affecting Copilot's Kimi K3 requests on August 27.
The August 17 incident alone was serious enough that CloudBees CEO Moritz Plassnig told DevOps.com at the time that "developers have been frustrated with GitHub's reliability for months, and today's outage is part of a bigger shift" — pointing to that outage's roughly 20% error rate on web/API traffic and 50% error rate on repository downloads, reportedly affecting a platform GitHub says has around 180 million users. September 13 continues that pattern rather than breaking it, and the common threads GitHub itself calls out across incidents — insufficient capacity headroom, retry amplification, and shared infrastructure straining under growth — are the same threads present in the September 13 writeup.
What this changes
For most engineering teams, this isn't a reason to distrust GitHub specifically — it's a free, well-documented worked example of failure modes worth checking for in your own systems, whether or not you run anything at GitHub's scale:
- Health checks need to watch the resource that can actually saturate, not just the easiest one to measure. Replica lag is a fine signal for read-scaling problems; it tells you nothing about primary-node connection exhaustion. If a background job's throttle depends on one metric, ask what failure mode that metric is blind to.
- Shared databases on the authentication/authorization path are a single point of blast-radius expansion. If your permission checks, session validation, or entitlement lookups share infrastructure with anything else — batch jobs, analytics writes, cleanup tasks — that infrastructure inherits the criticality of the auth path, whether or not anyone designed it that way.
- Long timeouts plus naive retries is a saturation amplifier, not a resilience feature. Failing fast and backing off (ideally with jitter and a circuit breaker) protects a struggling dependency; waiting and retrying blindly protects nothing and can turn a partial degradation into a full outage.
- Background/maintenance jobs deserve the same load-testing and staged-rollout discipline as user-facing changes. A cleanup job is still a job that writes to production infrastructure; it should be rate-limited against the metric that actually matters, not the one that was easiest to wire up.
None of this means GitHub is uniquely fragile — publishing detailed postmortems like this one is a genuine transparency practice worth crediting, and it's what makes an article like this possible. The practical takeaway is narrower and more useful: go check whether your own "boring" background jobs share a database with something on your auth path, and whether your health checks would actually catch it if they didn't.
If you're evaluating your own platform's reliability posture around shared infrastructure and incident response, that's the kind of engineering work we do at Wise Hustlers — see our services for more on how we approach it.