Incident with several GitHub Services
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 j
The latest update from GitHub.
State
Resolved
Started
49 d ago
2026-09-13 09:16 UTC
Lasted
1 h 29 min
until 2026-09-13 10:44 UTC
Worst impact
Major outage
Timeline
6 updatesInvestigating
1 h 29 min 100%
Updates
Times in UTCAs posted by GitHub
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 j
Pull Requests is experiencing degraded performance. We are continuing to investigate.
We have reduced load on this cluster with internal load-shedding and are seeing signs of recovery but continue to monitor
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
Actions is experiencing degraded performance. We are continuing to investigate.
We are investigating reports of degraded availability for API Requests, Issues, Pages and Pull Requests
Affected components
5GitHub in the last 90 days
Full historyIncidents in 90 days
46
Days with an incident
34
Median duration
1 h 29 min
This incident
About the median
Other GitHub incidents
All incidentsGitHub·Incident with Dependabot
This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.
GitHub·Incident with Actions, Pages, and Webhooks
This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.
GitHub·Disruption with GitHub services
This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.
GitHub·Disruption with Copilot Cloud services
This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.
GitHub·Disruption with some Copilot services
This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.
Follow GitHub
Your coding agent knows when GitHub is down, and tells you when a failure is theirs, not yours. You can also get GitHub incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "github" and tell me if GitHub has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=github/feed subscribe https://outages.cc/feed.xml?providers=githubFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane