The GitHub outage Monday morning disrupted developers worldwide for more than three hours, with GeekWire reporting the Microsoft-owned code-sharing platform’s 225 million users found themselves locked out, slowed down, or otherwise stuck from shortly before 7 a.m. Pacific time.
If your Monday morning felt unusually calm on the coding front, now you know why. Downdetector logged over 3,000 user reports flagging issues with the service, and the comments section was, let’s say, candid. ‘Cmon [GitHub] get your sh*t together… this is getting old,’ one user wrote. The asterisks were their own addition.
GitHub Outage Monday Morning: What Actually Broke
According to GeekWire, the problem began at 6:40 a.m. Pacific. Within roughly an hour and a half, the damage had spread well beyond a simple slowdown. The GitHub website itself went down, as did tools for reviewing and merging code, the automated systems that test and ship software, and the GitHub Copilot AI coding assistant. In other words: nearly everything.
DevOps.com reported that at the peak of the incident, GitHub confirmed error rates of approximately 20% across its web interface and API traffic. Raw repository content and archive downloads were hit harder, with error rates near 50%. Enterprise authentication features, including SAML, OIDC, SCIM and Team Sync, were broadly impacted too. So if your organisation runs any kind of automated deployment or single sign-on setup through GitHub, Monday was not a good day for that.
The breadth of it is worth sitting with for a moment. This was not a case of one service degrading while everything else ticked along. Copilot going down alongside the core repository tools and the authentication layer simultaneously points to something fairly deep in the stack going wrong, though GitHub had not publicly detailed the root cause at the time of writing.
How Long the Disruption Lasted and When Things Recovered
GeekWire reports that GitHub identified the source of the problem shortly after 9:30 a.m. Pacific and had the outage under control by 10 a.m., with services beginning to recover from that point. That puts the total disruption window at roughly three and a quarter hours from the first signs of trouble to the platform getting itself back together.
For developers in the UK and Europe, the timing was particularly sharp. The outage started at around 2:40 p.m. GMT, landing squarely in the middle of the working afternoon. Anyone trying to push code, open a pull request, or run a pipeline during that window would have run into it at full force.
The Downdetector comments suggest Monday was not an isolated incident either. Scrolling back through the history, users had been reporting errors once or twice a week throughout August. Whether those were related issues or separate, smaller problems is not clear, but the frustration in the comments does not read like people encountering something for the first time.
GitHub’s status page confirmed the timeline of the resolution, which at least shows the team was on it and communicating publicly as things developed. That is something, even if it does not make up for a lost morning of work for developers across the globe.
GitHub had not issued a detailed post-mortem at the time of writing, but the status page confirmed that services were recovering by 10 a.m. Pacific, and GeekWire noted the platform had the outage under control from that point. Whether a fuller explanation follows is a question of when, not if, given GitHub’s usual practice after incidents of this scale.
