GitHub Outage: What 10 Hours of Downtime Costs a Business
Sharan Sifat14 min read3 viewsOn 6 August 2026 GitHub Actions stalled for more than ten hours and took Pages, Copilot and webhook delivery with it. A practical look at what actually broke, what a frozen pipeline costs a business, and the resilience steps that limit the damage.
On this page
On 6 August 2026, GitHub Actions stopped working properly for most of a working day. GitHub opened the incident at 15:22 UTC and did not post a resolution until 02:04 UTC the next morning — more than ten hours later. If your team could not deploy that afternoon, that is why, and it was not your pipeline's fault.
The part that surprised people was the blast radius. This was not only a GitHub outage affecting builds. GitHub Pages, Copilot code review, the Copilot coding agent, hosted and self-hosted runners, webhook delivery and Enterprise Importer migrations were all named on the status page. One dependency failed and took a working day's worth of shipping with it.
This article is the practical version, written for the founder who got a Slack message saying "we can't deploy" and needed to know how bad it was. What actually broke, what a frozen pipeline genuinely costs, and — the part worth your time — the specific things you can put in place so the next one is an inconvenience rather than a stop-work order.
- GitHub's 6 August 2026 Actions incident ran from 15:22 UTC to a resolution post at 02:04 UTC the following day.
- The impact spread well past builds: Pages, Copilot, webhooks, hosted and self-hosted runners and migrations were all affected.
- GitHub said it had identified a cause about two hours in, but no public root-cause explanation followed.
- This was not isolated — The Register counted 26 incidents on GitHub's status page in April, 23 in May, 23 in June and 26 in July.
- You cannot prevent a vendor outage; you can make sure it does not also block hotfixes, releases and your customers.
What actually happened on 6 August 2026
GitHub opened an incident for degraded Actions performance at 15:22 UTC. Within about twenty minutes it had escalated to availability degradation, and by roughly 16:02 UTC the status page confirmed workflow failures and API errors, according to The Register's coverage.
Mitigation was not called until 00:05 UTC on 7 August, with the resolution post following at 02:04 UTC — an incident that ran, start to finish, for around ten and a half hours, per IncidentHub's timeline reconstruction. For a service that sits between every commit and every deploy, that is a long time.
The blast radius was wider than Actions
The services GitHub named on its own status page during the incident tell the real story. Affected: Actions, Pages, Copilot code review, the Copilot coding agent, hosted runners, self-hosted runners, webhook deliveries, and migrations using GitHub Enterprise Importer.
What that meant in practice for teams:
- Workflow runs failing to start, failing partway through, staying queued, or timing out.
- Actions REST API errors and unexpected rate limiting.
- Runners receiving invalid job assignments, and self-hosted runner registration errors — so even teams running their own compute were not insulated.
- Pages deployments lagging, which takes down documentation and marketing sites built on it.
- Webhook throughput throttled during recovery — reported at roughly 15% at one point — meaning many push and pull request events simply never triggered a workflow at all.
That last one is the sneaky failure. A workflow that never starts does not appear as a red build. It appears as nothing, which is far harder to notice than a failure.
During the recovery window, some events were dropped rather than delayed. If you deployed on 6–7 August, re-check that the commits you expected to ship actually ran their pipeline. A silent skip looks exactly like a green board.
What GitHub did and did not say
GitHub told users roughly two hours in that its engineers had identified the source of the disruption. It then never published what that source was. The Register noted the same gap: mitigations were applied and a fix rolled out, but administrators were left without a root-cause explanation for an outage that stalled both CI/CD and parts of GitHub's AI-assisted development stack.
To be fair to GitHub, its monthly availability reports are genuinely detailed after the fact — the June 2026 edition, for example, documents six incidents with real numbers: a Copilot code review failure affecting 81.6% of requests at a 1 hour 25 minute duration, elevated HTTP 504s for unauthenticated users traced to a surge in abusive automated traffic, and an API authentication failure affecting 9% of requests caused by a memcached proxy rollout picking up an incorrect host configuration.
That is a good standard of disclosure. It just arrives weeks later, which is no help on the day.
Why this one stung more than a normal outage
Every platform has bad days. The reason this one landed differently is that it did not feel like a bad day — it felt like a pattern. The Register's tally of incidents logged on GitHub's status page through 2026 is not a comfortable line to read.
| Month (2026) | Incidents logged on GitHub's status page |
|---|---|
| April | 26 |
| May | 23 |
| June | 23 |
| July | 26 |
| August (first six days) | 6 |
Not every one of those is an outage — the status page logs degradations, partial incidents and short blips alongside major events. But the trend is the point. GitHub's SVP Jakub Oleksy publicly committed in June to structural improvements intended to "permanently remove failure modes", and incidents continued at a similar rate afterwards. GitHub has also pointed to surging AI-driven usage stressing its systems.
The developer reaction has been correspondingly blunt. Ghostty's Mitchell Hashimoto said the platform had become unstable enough that it is no longer somewhere to host "serious work" — a striking thing to hear about the default home of open source.
Your deploy pipeline is a vendor dependency with no SLA to you — the outage is not your fault, but the standstill is your problem.
The pattern behind the headline
Worth keeping in perspective: this was still not GitHub's worst Actions day. IncidentHub's records put the longest prior major Actions outage at 8 hours 11 minutes, back on 16 May 2021. And a smaller Actions incident on 29 July 2026 ran only about 37 minutes, with a cause that was disclosed — an under-provisioned internal service running out of memory.
The honest read is not "GitHub is broken". It is that a platform which used to be background infrastructure now needs to be treated as an active dependency in your architecture. That is a planning change, not a panic.
What a stalled pipeline actually costs a business
Founders tend to price downtime as lost engineering hours. That is the smallest part of the bill.
The three costs founders underestimate
1. The hotfix you could not ship. Ordinary feature work waits happily. A production bug does not. If your only path to production runs through a broken CI provider, an unrelated vendor outage has just extended your customer-facing incident by however long theirs lasts. This is the cost that actually matters, and it is the one worth engineering against.
2. The restart tax. A ten-hour outage does not cost ten hours. It costs the deploys that queued up, the merge conflicts that accumulated while nothing landed, the release that slipped to the following morning, and the hour the team spent watching a status page instead of working. Recovery work is real work.
3. The commitments made on the assumption of a normal day. A demo booked for Friday. A client launch. A marketing site update timed to an announcement. These are the ones that turn an engineering annoyance into a commercial conversation, and they are the reason your delivery plan should have slack in it — the same reasoning behind the buffers in our production launch checklist for Django applications.
If you are a small team, do the maths honestly before over-engineering. A handful of lost afternoons per year may genuinely cost less than maintaining a second, always-warm deployment path. The goal is a considered decision, not maximum redundancy.
The dependency map most teams have never drawn
Ask a founder what happens if GitHub goes down and the usual answer is "we can't deploy". The real answer is longer, and writing it out is a genuinely useful thirty-minute exercise.
| Function | What breaks when GitHub is degraded | Realistic fallback |
|---|---|---|
| Deploying to production | Actions workflows queue, fail or never trigger | A documented manual deploy path from a developer machine or your host's CLI |
| Code review and merging | Required status checks never report, so protected branches block merges | A named person with admin rights who can bypass checks in a declared emergency |
| Docs and marketing sites on Pages | Deployments lag or fail; the live site may be fine but frozen | Host the marketing site somewhere separate from your code platform |
| Integrations driven by webhooks | Events delayed or dropped entirely — no error surfaces | Reconciliation job that replays missed events from source state |
| Package and image pulls | Builds that fetch dependencies from the same platform fail mid-run | A cache or mirror for critical dependencies |
| AI-assisted review | Copilot review and coding agent unavailable | Human review — which should never have been fully replaced anyway |
The row people miss is the second one. Branch protection rules turn a CI outage into a merge freeze. If your main branch requires status checks that a broken provider cannot deliver, nobody can merge anything — including the fix. That is a configuration decision you made months ago quietly becoming a business constraint.
How to keep shipping when your CI provider is down
None of what follows is exotic. It is the boring preparation that separates a team that shrugs at an outage from one that loses a day.
- Write down the manual deploy path — and test it once. A short runbook: which command, from which machine, with which credentials, and who is allowed to run it. Untested runbooks are fiction. Run it once a quarter on a real deploy so you know it works.
- Decide your branch-protection break-glass rule in advance. Who can bypass required checks, under what circumstances, and what they must do afterwards (open a follow-up PR, re-run the suite when the provider recovers). Decide it calmly now, not during an incident.
- Keep the ability to build locally. If your application can only be built inside a CI runner, you have coupled your build to a vendor. A developer should be able to produce a deployable artifact on a laptop.
- Do not host your marketing site on the same platform as your code. Cheap separation, meaningful benefit — your public presence stays live and updatable when your development platform is not.
- Make webhook consumers idempotent and reconcilable. Assume events arrive twice, late, or never. A nightly reconciliation against source state catches what delivery dropped.
- Subscribe to the status page properly. Not "someone will notice" — an actual subscription routed into the channel your team watches. Twenty minutes of confused debugging before realising it is the vendor is entirely avoidable.
- Check for silent skips after any CI incident. Compare merged commits against pipeline runs for the outage window. This takes five minutes and occasionally saves a very awkward week.
The single highest-value item on that list is number one. A tested manual deploy path converts "we are blocked until GitHub recovers" into "we shipped the hotfix, the rest can wait." It costs an afternoon to set up.
What we build in on client projects
We are a Django and Next.js shop, and our defaults on this are deliberately unglamorous. Every project gets a deployment runbook written by the engineer who set up the pipeline, not by someone documenting it later from memory. Every project keeps a build path that works outside CI. And branch protection is configured with an explicit, named break-glass owner rather than a rule nobody can override.
Where we do not add redundancy
We generally do not run a mirrored CI provider on standby for small teams. Maintaining two pipelines means two sets of secrets, two configurations that drift apart, and a second thing to debug — and the drift means the backup is often broken precisely when you reach for it. The cheaper, more reliable insurance is a manual path a human can execute.
We also do not move clients off GitHub because of an outage. Migration has real costs — issues, actions, integrations, muscle memory — and the alternatives have their own bad weeks. If you are inheriting a codebase and want to know how we assess this kind of operational risk, that process is much the same as the one in our guide to taking over and stabilising an existing web application.
Where the real fragility usually is
In our experience the CI provider is rarely the weakest link in a client's stack. It is the deploy step that only one person understands, the credentials stored in one engineer's password manager, the pipeline that has never been run end to end from scratch. A vendor outage is simply the event that exposes those. That is why this belongs in the same conversation as ongoing application maintenance and support rather than being treated as a one-off scare.
Should you leave GitHub over this?
Almost certainly not — but the question deserves a straight answer rather than a reflex.
Reasons that genuinely justify moving: a compliance requirement for self-hosted source control; an enterprise environment where you already run your own infrastructure; or a documented, repeated pattern of outages that has measurably cost you delivery commitments over several quarters.
Reasons that do not: one bad day, however long. Frustration. A widely-shared post from a developer you respect. The alternatives — GitLab, self-hosted forges, Bitbucket — all have incident histories of their own, and you would be trading a known failure profile for an unknown one plus a migration project.
The more useful reframe is that portability is worth more than platform choice. Keep your pipeline definitions as plain, readable configuration. Avoid deep coupling to one vendor's proprietary features where a standard alternative exists. Then, if you ever do need to move, it is a project rather than a rebuild — the same portability logic we apply to choosing a tech stack in the first place.
Frequently asked questions
Is GitHub down right now?
The authoritative answer is always GitHub's own status page rather than a third-party tracker. The 6 August 2026 incident was posted as resolved at 02:04 UTC on 7 August, and GitHub subsequently reported all systems operational. If your builds are failing and the status page is green, the problem is more likely to be in your workflow configuration or a rate limit than in the platform.
What caused the August 2026 GitHub outage?
GitHub said about two hours into the incident that its engineers had identified the source, but it did not publish a root-cause explanation at the time. GitHub does publish detailed monthly availability reports after the fact, so a fuller account is likely to appear there rather than on the status page.
Were self-hosted runners protected from the outage?
No. Self-hosted runners were explicitly named among the affected components, with registration errors and invalid job assignments reported. Running your own compute does not remove the dependency on GitHub's orchestration and control plane — a distinction worth understanding before you assume self-hosting is insulation.
How do I know whether my commits actually deployed during an outage?
Compare the commits merged during the incident window against the pipeline runs that exist for them. Because webhook delivery was throttled, some events never triggered a workflow at all — which shows up as an absent run rather than a failed one, so a green dashboard is not proof.
Is it worth setting up a second CI provider as a backup?
For most small and mid-sized teams, no. Two pipelines mean two sets of secrets and two configurations that quietly drift apart, so the standby is often broken when you finally need it. A tested manual deploy path delivers most of the benefit for a fraction of the maintenance.
How often does GitHub actually have incidents?
More often than most people assume. The Register counted 26 incidents logged on GitHub's status page in April 2026, 23 in May, 23 in June and 26 in July. Most are short degradations rather than full outages, but the volume is the reason to plan for interruption as a normal condition rather than an emergency.
Not sure how your deployment would hold up on a day like this? Get a free scope and quote — we will review your pipeline, your fallback path and the single points of failure nobody has written down yet. You can also read more of our work on reliability in security and DevOps.
Sources
- GitHub Status — official incident status and history
- GitHub availability report: June 2026 — The GitHub Blog
- Latest GitHub outage squeezes Actions, Pages to death — The Register, 6 August 2026
- GitHub outages persist as AI coding drives traffic surge — The Register, 12 June 2026
- The August 6, 2026 GitHub Actions Outage — IncidentHub incident analysis
Have a project like this in mind?
Tell us what you're building and we'll map out the scope, timeline and a fixed starting quote — no obligation.
Start your project
