GitHub Wobbled Three Separate Times in Eight Days: What Owning No Runner Capacity Costs

Between July 2 and July 9, 2026, GitHub logged three independent incidents that each touched a different piece of a typical deploy pipeline. Not three retries of the same root cause — three separate subsystems, failing for three separate reasons, in the same eight-day window.

Here's the full accounting, straight from GitHub's own status history:

Three Root Causes Is a Different Risk Shape Than One Outage Repeating​

If GitHub had the same incident three times in eight days — say, the same backend data service failing on July 2, 7, and 9 — that would be a story about one fragile component. Fix that component, and the risk goes away.

That's not what happened. A demand-driven capacity ceiling on the Pages deployment pipeline, an API-layer 500-error spike on the Actions/Codespaces control plane, and an unhealthy data service in runner provisioning are three unrelated systems, each with its own failure mode, each independently having a bad day inside the same calendar week. There's no single fix that makes all three go away, because there's no single thing that broke three times — there are three different things that each broke once.

That matters for how you should actually reason about vendor risk. "GitHub is down" isn't one failure surface you can route around by avoiding one feature — it's a bundle of independently-failing subsystems, and a team's deploy pipeline typically touches all three: the git host that receives the push, the CI layer that builds and tests, and — for anyone serving a static site or docs from Pages — the deploy target itself. None of July's three incidents happened to hit git push or repository hosting directly. But that's a fact about which subsystems had a bad week, not a guarantee about which ones will next time — GitHub is your git host, your CI runner, and (for Pages users) your deploy target, all under one roof, whether or not this particular eight-day window happened to demonstrate every leg of that at once.

Mapping Each Incident to a Pipeline Stage​

Translate the three incidents into the stages of an ordinary git-push deploy flow, and the pattern is that each one hit a different link in the chain:

• July 2 (Pages, 15:00–18:30 UTC) — the deploy target itself. If your production destination is GitHub Pages, this isn't "CI was slow" — the place your site lives stopped accepting new versions. A push during that 3.5-hour window either queued behind the backlog or landed degraded. There's no fallback deploy target when the deploy target is down.
• July 7 (Actions & Codespaces APIs, 14:01–16:17 UTC) — the trigger and dev-environment layer. With up to 8% of Actions runner API calls and 13% of Codespaces API calls failing, this is the layer that starts a workflow and spins up a cloud dev environment misbehaving. Runs already in progress mostly kept going; it's the next push, the next PR, the next Codespace launch that hits an intermittent 500 and has to be retried by hand.
• July 9 (hosted-runner provisioning, 03:29–13:39 UTC) — the build execution layer. This is the one that stings longest: 10 hours, ~8% of workflow starts delayed past 5 minutes, ~2% failing to acquire a runner at all. A workflow that can't even get a runner assigned doesn't fail loudly — it just sits queued, and a team watching a stalled "Merge" button has no way to tell whether the fix is en route or the job silently died.

Three incidents, three different failure experiences: unreachable destination, flaky trigger, stalled execution. A team relying on GitHub end-to-end — Pages for the site, Actions for CI, hosted runners for compute — had a plausible bad day on all three fronts within the same week, with no single workaround available for any of them, because the fix in each case was "wait for GitHub to resolve it."

This Wasn't a Fluke Month — It's Denser Than the Baseline​

It's tempting to read three incidents in eight days as an unlucky cluster inside an otherwise-stable year. GitHub's own monthly availability reports say otherwise:

That's an average of six incidents a month — one every five days — across the first half of 2026. Three incidents in an eight-day window isn't an outlier spike against that baseline; it's roughly what "average" looks like when it happens to cluster instead of spreading evenly across the month. The honest reading isn't "GitHub had a uniquely bad week in July" — it's "a multi-incident week is the expected texture of depending on any single vendor for git hosting, CI, and static-site deployment at once, and July 2–9 is just the week it happened to land on the calendar in a way a blog post could describe."

Why "Just Add a Self-Hosted Runner" Doesn't Fully Fix It​

GitHub itself offers a partial mitigation for one of the three incidents: self-hosted Actions runners let a team supply its own compute instead of waiting on GitHub-hosted runner provisioning, which would have sidestepped July 9's stalled workflow starts. It's a real option, and teams already running their own build boxes should use it.

But it only patches the July 9 failure mode. A self-hosted runner still receives its job through the Actions control-plane API — the same API that returned intermittent 500s on July 7. And a self-hosted runner has no opinion at all about where the built artifact ends up; if that destination is GitHub Pages, July 2's capacity ceiling is untouched no matter how much compute a team owns. Self-hosted runners solve "GitHub can't find me a machine," not "GitHub's control plane is flaky" or "GitHub's deploy target is saturated." Each of the three incidents needs its own workaround, bolted onto an architecture that still routes trigger, build, and deploy through the same vendor's infrastructure — which is a fragile way to buy back reliability one subsystem at a time versus removing two of the three subsystems from GitHub's infrastructure altogether.

What Owning the Build Step Actually Changes​

Replay the same three incidents against a git-push PaaS whose build execution and deploy target run on a team's own Cluster API-managed fleet instead of GitHub's infrastructure — that's the model bex is built on — and the picture splits cleanly:

• July 2 (Pages outage) — moves. The deploy target is no longer GitHub's infrastructure; it's the tenant's own machines, running an HTTPS service the platform provisioned. A GitHub-side capacity ceiling on Pages has nothing to do with whether that service stays reachable.
• July 7 (Actions/Codespaces API errors) — partially moves. The build and deploy pipeline no longer depends on GitHub's Actions runner API or Codespaces API at all — those aren't in the path. What's left is the webhook that tells the platform a push happened.
• July 9 (hosted-runner provisioning) — moves. Build execution runs on owned Hetzner capacity the platform's own control plane schedules, not on GitHub's runner-acquisition backend. A backend data service failing inside GitHub's infrastructure has no way to stall a build that never asks GitHub for a runner in the first place.

The one piece that doesn't move: the webhook trigger, and git hosting itself. Unless a team also self-hosts its git remote, GitHub is still the system of record for the push that kicks the whole thing off — an incident that breaks GitHub's webhook delivery (not one of these three, but a real category of prior GitHub incidents) still delays when the platform learns a deploy is needed, even if the build and deploy that follow run entirely on owned infrastructure.

That's the honest scope of the tradeoff: owning the build step and the deploy target removes two of the three failure modes July's incidents demonstrated — build execution and deploy-target availability — and shrinks the blast radius of the third (the control-plane API layer) down to "delayed trigger" instead of "delayed trigger and delayed build and unreachable deploy target." It doesn't remove GitHub from the picture entirely, and it shouldn't be sold as if it does. What it buys is real: a GitHub incident that used to be able to hit all three of "can I push," "will it build," and "is my site up" now only ever touches the first one.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. The build step and the deploy target run on your own Cluster API-managed fleet, so a GitHub incident only ever touches the webhook trigger. Star the repo on GitHub or deploy your first app today.

Sources​

• GitHub Status: GitHub Pages degraded deployments, July 2, 2026
• GitHub Status: Actions and Codespaces APIs experiencing partial failures, July 7, 2026
• GitHub Status: Hosted-runner provisioning delays, July 9, 2026
• GitHub availability report: January 2026
• GitHub availability report: February 2026
• GitHub availability report: March 2026
• GitHub availability report: April 2026
• GitHub availability report: May 2026
• GitHub availability report: June 2026