GitHub outage on September 13, 2026: Incident with several GitHub Services
GitHub reported an incident affecting GitHub for 1 hour 29 minutes on 13 September 2026, from 09:16 to 10:44 UTC.
Resolved
Official incident reported by GitHub
- Started
- 09:16
- 13 Sep 2026 UTC
- Resolved
- 10:44
- 13 Sep 2026 UTC
- Duration
- 1h 29m
- 1 hour 29 minutes
- Impact
- Critical
- as rated by GitHub
- Updates
- 6
- posted by GitHub
Timeline
All times UTC.
Official incident from GitHub
Incident with several GitHub Services
-
Official
Investigating
We are investigating reports of degraded availability for API Requests, Issues, Pages and Pull Requests
-
Official
Investigating
Actions is experiencing degraded performance. We are continuing to investigate.
-
Official
Investigating
We're seeing increased database replication delays on collab which is causing increased error rates in authorization endpoints and follow-on increased error rates across the system - we are investigating
-
Official
Investigating
We have reduced load on this cluster with internal load-shedding and are seeing signs of recovery but continue to monitor
-
Official
Investigating
Pull Requests is experiencing degraded performance. We are continuing to investigate.
-
Official
Resolved
On September 13, 2026, between 08:43 and 10:44 UTC, GitHub experienced degraded availability across approximately 28 services, including Issues, Pull Requests, Actions, Codespaces, Pages, Notifications, Code Scanning, Git LFS, and new account signup. At peak, 8.8% of requests to create GitHub App installation access tokens failed. Token issuance for Actions workflows was also affected, impacting approximately 4% of workflows during the incident time frame. Creating issues through the web interface failed for about 96% of attempts, and signup failures were above 90%. The cause was an internal data-cleanup job that began writing to a shared database cluster at 07:33 UTC. That cluster stores permission data read on nearly every authenticated request. The safeguard that was pacing the background job watched only one health signal — how far the database replicas were lagging — and that signal stayed low the whole time. It did not account for the load building on the primary itself, so the job kept writing while the primary quietly ran toward its limit. When the primary ran out of available connections, requests that needed it could not complete. First, there was...
"Official" rows are quoted from GitHub's public status page, www.githubstatus.com. Very long posts are shortened.
What our checkpoints saw
HostTracker's checkpoints, which test github.com from several locations, recorded no outage of 5 minutes or longer during this incident. A provider can report a problem that affects only some features, regions or accounts, which a check of the main address does not see. The live GitHub status shows what our checks see right now.
Does your product depend on GitHub?
An outage like this one reaches your users through your product, and most teams hear about it from a customer rather than from a dashboard. HostTracker watches any endpoint you name - your own site, an API you call, a vendor you resell - from 300+ locations, confirms a failure from several of them before it says anything, and then tells you by email, SMS, voice call or your chat tool.
You get the same record you are reading here for your own services: every outage timestamped, with the checks that observed it.
Independent measurement by HostTracker. Not affiliated with GitHub. Official updates are quoted from GitHub's public status page and remain GitHub's own words.