GitHub's September Reliability Deadline Arrived. The Incident Record Says It Missed.

In early June, GitHub COO Kyle Daigle made a bet in public: within three months, the platform would show "fewer and fewer moments where we have an availability problem." September 2026 was the deadline. September is here — and three days ago, API requests, Issues, pull requests, Actions, and Pages all degraded together.

The verdict is in: GitHub missed its own deadline. The more important question for anyone running a deploy-from-git pipeline is what you do about it, because the September 13 incident hit the exact surface your deploys depend on: the webhook trigger, the Actions queue, and the APIs around them.

What was actually promised​

Daigle's June remarks came with unusual candor about the cause. Commit volume had gone from roughly 1 billion in all of 2025 to about 1.4 billion per month, with AI agents generating more than 17 million pull requests a month — up from 4 million in September 2025. Actions minutes had climbed from 500 million a week in 2023 to 2.1 billion. Automated traffic was growing eight times faster than human traffic.

"It's now material change that takes a bit of time and then you see a step change in our availability," Daigle said, predicting that "in the next 3 months you're going to see like fewer and fewer moments where we have an availability problem where things are going to go down."

The context made the promise dramatic. In April, GitHub had announced an "Availability First" strategic pivot, with CTO Vladimir Fedorov admitting the platform was designed for 10x scale and had discovered it needed 30x. In June, Microsoft confirmed it was routing GitHub traffic through AWS to absorb the surge. The September deadline was supposed to mark the step change — the point where the rewrites and the extra capacity started showing up as fewer incidents.

The incident record, scored against the promise​

Here is what happened between the promise and the deadline:

That is not a curve bending toward fewer incidents. August alone contained an outage that consumed the year's entire three-nines downtime budget in a single day, according to contemporary coverage — and September opened with a five-service degradation, not a clean sheet.

The August 17 root cause is worth remembering because it previews the failure mode that keeps recurring. GitHub traced the nearly eight-hour outage to saturated load balancers in its Central US datacenter, caused by a service-mesh autoscaling misconfiguration and amplified by retry storms — including what GitHub called a "latent retry bug in Visual Studio Code." When clients hammer a struggling control plane with retries, the retries become part of the outage. GitHub's own September-era assessment of a related August failure was blunter still: "Our shared infrastructure services have not kept up with our month-over-month actions growth and peak load."

Meanwhile the ecosystem started hedging. Zig had already moved to Codeberg in November 2025; Ghostty left GitHub in April 2026; and as GitHub staggered through the August 17 outage, Cursor announced an early beta of Origin Code Hosting. Nobody migrates a forge over one bad day. They migrate when the bad days form a pattern.

Why September 13 is the one that matters for deploy pipelines​

Not every incident in that table threatens your deploys equally, and the distinction matters.

The July 19 certificate expiry was spectacular — every self-hosted runner on the planet dropped at once, around 23:05 UTC, with recovery beginning at 02:45 UTC — but its blast radius was narrow: runner dispatch only. The irony (valid replacement certificates had been issued in May, June, and twice on July 10; the renewal automation was firing while the serving layer kept handing out the expired one) is an ops-cautionary tale, not a pipeline-design lesson. If your runners are GitHub-hosted, you slept through it.

September 13 was the opposite shape: shorter, but aimed at the shared trigger-and-queue surface every deploy-from-git pipeline stands on. From 09:16 to 10:44 UTC, API requests, Issues, pull requests, Actions, and Pages were degraded together. That combination breaks the deploy path at three points at once:

• The trigger goes quiet. No webhook delivery, no deploy. Pushes land in the repo while nothing downstream notices, and the gap is silent unless you are watching for it.
• The queue goes opaque. Actions runs sit queued or fail to start, and "queued" looks identical whether GitHub will pick the job up in a minute or after the incident resolves.
• The surrounding APIs 500. Real reports from that morning show Pages deployment APIs returning HTTP 500 and GitHub App token mints failing — the calls a pipeline makes to do the deploy and to authenticate it, both flaky at once.

July 19 took out one kind of runner. September 13 took out the trigger, the build queue, and the deploy APIs simultaneously. If your entire release path is "GitHub webhook fires, Actions builds, Pages or an API call ships it," September 13 was a total deploy freeze with no action available on your side — unless you had built for it.

The three things a git-push pipeline needs now​

Treating github.com as load-bearing infrastructure means designing for its degraded windows, not just its happy path. Three mechanisms cover most of the gap.

1. Webhook retry and replay automation​

The single most under-appreciated fact in this whole story: GitHub does not automatically redeliver failed webhook deliveries. If a push-event delivery fails during a degraded window, it stays failed until someone — or something — redelivers it. Redelivery is available for seven days and requires admin access on the repo, but nothing happens on its own.

GitHub's own docs describe the automation pattern: poll the deliveries API, group by GUID, and redeliver one failed delivery per GUID that never succeeded. Any deploy-from-git platform should be running that loop continuously, not reaching for the "Redeliver" button by hand after an incident. Concretely:

• Run a scheduled reconciliation job that lists recent deliveries and redelivers failures, so a quiet trigger window self-heals within minutes of recovery.
• Treat a missing webhook as an expected event, not an anomaly: if a push exists in the repo with no corresponding pipeline run after N minutes, create the run.
• Remember the seven-day window — replay older than that is gone, which bounds how long a "we'll catch up after the incident" strategy can stretch.

2. Queue visibility during degraded windows​

When Actions is degraded, every pipeline dashboard shows the same misleading state: jobs queued, nothing running, no errors yet. Operators cannot tell "backed up for two minutes" from "nothing will start until GitHub recovers," so they wait — and then discover after resolution that half the queued jobs timed out and need re-runs.

Fix this with explicit queue-age awareness:

• Alert on queue age, not just failure: a job queued longer than your p99 start time during a known GitHub incident is a forecast, not a status.
• Surface GitHub's status alongside your own: if the platform is degraded, say so in the deploy UI instead of letting "queued" imply "working."
• After recovery, assume queued jobs are suspect. Re-run rather than trust anything that sat through the window — the August 6 outage specifically warned that queued jobs may time out.

3. A degraded-mode deploy path​

The deepest fix is architectural: a deploy path that does not require github.com to be healthy. That does not mean leaving GitHub — it means your pipeline has a second gear:

• Poll fallback for the trigger. If webhooks go quiet, poll the repo for new commits on deploy branches. Webhooks are a latency optimization; the commit list is the source of truth.
• Manual dispatch that actually works. A "deploy this SHA now" button that depends on the same Actions queue you are trying to route around is decoration. The manual path should be able to build and ship with minimal GitHub API dependence.
• A mirror as a release source. A continuously synced mirror (another forge, or even a local bare repo updated by a cron fetch) lets the deploy side keep reading commits and tarballs when API and raw-content downloads are erroring at 50 percent.

None of this is exotic. It is the same "assume the dependency fails" discipline teams already apply to DNS, registries, and cloud APIs — finally extended to the forge, which spent years earning an exemption it no longer deserves.

What to watch next​

Two signals will tell us whether September was the bottom or just another data point. First, GitHub promised full RCA details in its September availability report — the August postmortems were frank about autoscaling and retry storms, so the September edition is where the "step change in availability" either shows up in the data or gets quietly re-scoped. Second, watch the curve into Q4: Daigle's promise was about fewer moments, a frequency claim, and frequency is exactly what the July-to-September record contradicts.

Until the record bends, the rational posture is the one this post's checklist assumes: github.com is a dependency with a published status page and a 2026 history of multi-hour, multi-service incidents. Design the trigger, the queue, and the deploy path for the degraded window — and the next deadline GitHub sets for itself can be interesting news rather than a risk to your releases.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Deploy triggers, build queues, and recovery paths are platform concerns, not afterthoughts. Star the repo on GitHub or deploy your first app today.