GitHub has been broken worldwide since 13:40 UTC this morning, and as of 15:01 UTC it is still broken. Microsoft's developer platform is reporting major outages on Actions, Issues, Pull Requests, API Requests and Copilot, with roughly 20% of web and API traffic failing outright and close to half of all archive and raw file downloads erroring out. The detail that matters more than the outage itself: Git Operations are listed as fully operational. Code is still moving. Everything GitHub built on top of code is not.
No cause has been disclosed. The status page has repeated "we are continuing to investigate" for an hour and a half, which in practice means nobody has isolated the upstream failure yet. The shape of it, though, is familiar: one unexplained degradation spreading outward into five products in half an hour.
RelatedGitHub Ships Native Stacked Pull Requests in Preview
- Confirmed 13:40 UTC, August 17, 2026. GitHub reports error rates near 20% across web and API traffic, and near 50% for archive downloads and raw repository content.
- Major outage on five services. Actions, Issues, Pull Requests, API Requests and Copilot. Webhooks is partially out. SAML, OIDC, SCIM and Team Sync authentication are all affected.
- Git itself is fine. Git Operations, Packages, Pages and Codespaces are operational, so clone, fetch and push still work normally.
- Not an isolated event. Independent tracking counted 257 GitHub incidents between May 2025 and April 2026, 48 of them major, adding up to 112 hours and 18 minutes of major-outage downtime.
What is actually broken, and what still works?
GitHub's own component list splits cleanly, and the split is instructive. The things that failed are the things that require the central platform to answer a question about state: does this pull request exist, is this check passing, is this user still in the org. The things that survived are the things that move bytes.
| Service | Status at 15:01 UTC | What it blocks |
|---|---|---|
| API Requests | Major outage | Every integration, bot, and CLI call that is not raw Git |
| Actions | Major outage | CI runs, deploy pipelines, release automation |
| Pull Requests | Major outage | Review, approval, merge |
| Issues | Major outage | Triage, bug intake, project boards |
| Copilot | Major outage | Completions and chat in the IDE |
| Webhooks | Partial outage | Event delivery to external systems, unreliably |
| Git Operations | Operational | Nothing. Clone, fetch and push work. |
| Packages, Pages, Codespaces | Operational | Nothing reported |
Authentication is the piece most coverage is skipping, and it is the piece with the longest tail. SAML and OIDC sign-in, SCIM provisioning and Team Sync are all caught in this. That is not a developer productivity problem, it is an access control problem, and it runs in both directions.
Why did Git keep working while GitHub went down?
Because Git was designed for exactly this and GitHub was not. When you clone a repository you get a complete copy of its history, every commit and every object, on your own disk. The transport that syncs those objects is a narrow service: it negotiates which packfiles you are missing and streams them. It reads and writes large immutable blobs and it caches extremely well.
Pull requests, review state, Actions runs, webhook delivery queues and Copilot's repository context are a different animal. They live in centralized storage that the web tier and the API tier both fan out across dozens of internal services. Degrade one shared dependency in that fan-out and every product sitting on it degrades together. Watch the order of today's updates and you can see it propagate.
- 13:40 UTCGitHub begins investigating "impacted performance" on some services no component named yet
- 14:31 UTCCopilot degraded first named casualty, 51 minutes in
- 14:49 UTCIssues degraded
- 14:54 UTCPull Requests degraded
- 14:58 UTCActions and Webhooks degraded 20% error rate on web and API, 50% on archive and raw content
- 15:01 UTCAPI Requests degraded, investigation ongoing no root cause disclosed
- NextPost-incident detail in GitHub's monthly availability report where the Feb and Mar 2026 cascades were explained
Five services failing across thirty minutes is not five failures. It is one failure becoming visible in five places as each dependent product crosses its own alerting threshold.
Is this a pattern or bad luck?
It is a pattern, and the numbers are not close. Independent incident tracking logged 257 GitHub incidents between May 2025 and April 2026, classifying 48 as major, with 112 hours and 18 minutes of cumulative major-outage downtime. February 2026 alone produced 37 incidents, 7 of them major. The concentration by component is the useful part: Actions absorbed 57 outages in that window, roughly three times as many as core Git operations.
What did GitHub already promise to fix?
This is where today gets uncomfortable. In its April 2026 availability report, GitHub attributed a run of major disruptions to rapid growth, architectural coupling, and limits in how the system handles load. The worst of them, on February 9, was an overloaded database cluster responsible for authentication and user management, which buckled after configuration changes triggered excessive background processing.
GitHub named the systemic causes plainly: insufficient isolation between components, and inadequate backpressure. Tight coupling let a localized failure cascade, and the platform could not shed load from misbehaving or high-volume clients to protect itself. The stated remedies were decoupling services, better load shedding, improved traffic management, and more observability.
Now read today's timeline again. An unexplained performance problem, authentication surfaces affected, and five products falling over in sequence because they share a dependency. Whatever the root cause turns out to be, the blast radius is precisely the thing April's report said was being shrunk. Four months on, that radius still spans Issues, Pull Requests, Actions, Copilot and the API simultaneously.
RelatedGoogle Play Age Signals Goes Global: Inside the 4 Tiers
Who is actually paying for this?
Teams whose release gate is a green Actions check are stopped, full stop. Most will discover in the next hour whether they have a documented manual override, and most will find they do not. Partial webhook delivery is the sneakier hazard: consumers built around at-least-once delivery cope fine, consumers that quietly assume ordering or completeness will corrupt state and not notice until much later.
The SCIM and Team Sync failure deserves more attention than it will get. Enterprise provisioning and deprovisioning is queued behind this incident, which means an employee offboarded this morning may still have repository access right now. That is a compliance exposure with a paper trail, not an inconvenience.
Four things worth doing before recovery lands. Do not retry failed Actions runs in a loop, since you are adding load to a system already struggling to shed it. Use local Git for anything genuinely urgent, because the data plane is healthy. Plan to reconcile webhook-driven state after the window rather than trusting what arrived during it. And write down what you could not do today, because that list is your actual dependency map.
On the money side, independent analyses this year have measured GitHub below the three nines (99.9%) availability standard its Enterprise tier is marketed against. For Microsoft the meaningful exposure is not SLA credits, which are small, it is the argument a competitor gets to make in a renewal conversation. The signal to watch is GitHub Enterprise renewal churn over the next few quarters, not this morning's status page.
- The root cause, and whether it rhymes. If the post-incident write-up again names a shared database cluster or a missing backpressure control, April's remediation plan did not land.
- Actions incident count for August. There was already a widespread Actions degradation on August 6. Two majors in twelve days would put this month on pace with February's 37.
- Whether auth gets isolated. Authentication being caught in a general performance incident is the single most repeated element across GitHub's 2026 outages.
- Competitor positioning. GitLab and self-hosted Forgejo pitches are going to cite these numbers by name at the next enterprise renewal cycle.
Our take
The interesting failure here is architectural, not operational. Git already solved availability for the only asset that is irreplaceable, your source history, by handing every developer a complete replica. Then the industry spent fifteen years moving the parts that actually gate shipping, review state, CI, merge permissions, identity, into one centralized service with no equivalent fallback. Today shows what that trade costs: an organization can lose the ability to review, merge and deploy while the version control system underneath it is in perfect health.
GitHub will fix this incident, probably within hours. The durable question is for everyone else. If your ability to ship a hotfix routes entirely through github.com, you do not have a distributed version control system, you have a very good local cache of one. Worth finding out which today, while the answer is cheap.
- OfficialGitHub Status live component status and timestamped incident updates
- OfficialGitHub availability report, April 2026 GitHub's own account of the February and March cascades
- ReferenceInfoQ: GitHub acknowledges scaling and architectural weaknesses isolation and backpressure detail
- BenchmarkIncidentHub: GitHub outage history 2025 to 2026 257 incidents, 48 major, per-component counts
Original analysis by GenZTech, built from GitHub's live status timeline and its own April 2026 availability report. Outage first reported by BleepingComputer.