GitHub users report outage disrupting commits and Actions
Users reported failures retrieving commits, running Actions, and syncing GitHub-hosted repositories. Some developers said the disruption blocked pull-request merges amid broader reliability complaints.

TL;DR
- GitHub's Aug. 17 incident spread across API Requests, Actions, Pull Requests, Issues, Webhooks, Pages, Git Operations, and Copilot, with the status page reporting roughly 20% web/API errors and 50% errors for archive and raw-content downloads: GitHub status screenshot.
- Developers reported blocked PR merges Teknium's outage report, failed commit retrieval doodlestein's report, and CI failures Teknium's CI reply.
- GitHub marked the incident resolved at 21:15 UTC after repeated mitigations, while saying a detailed root-cause analysis would follow: GitHub status incident screenshot.
- Cursor began rolling out Origin, its hosted code service, on the same day, with GitHub sync still treating GitHub as the source of truth for synced repositories: kimmonismus's Origin summary.
GitHub's incident record includes a 20% web/API failure rate and 50% errors on archive and raw-repository downloads. Cursor's Origin changelog landed the same day with hosted repositories and two-way GitHub pull-request sync, while Doodlestein's local release fallback reuses existing Actions workflows when hosted queues fail.
Incident timeline
GitHub began investigating at 13:40 UTC on Aug. 17, according to its status timeline. BleepingComputer's report places that at 9:40 a.m. Eastern time.
- API Requests degraded at 13:41 UTC, Actions at 13:42, and Webhooks at 13:44.
- GitHub reported an approximate 20% error rate across numerous experiences at 13:45, then listed Issues, Pull Requests, and the web/API surface in subsequent updates.
- By 14:31, Copilot was degraded. Pull Requests were degraded at 14:45, and Actions were again listed at 14:58.
- GitHub said the degradation affecting API Requests, Actions, Git Operations, Issues, Pages, Pull Requests, and Webhooks had been mitigated at 16:59.
Users saw failures before the service inventory filled out. Teknium said he could not get PRs merged and described it as roughly the tenth GitHub failure in a few days Teknium's outage report. Doodlestein posted that the web app could not retrieve commits doodlestein's report, while legit_api said errors appeared across different parts of GitHub after initially suspecting his repository legit_api's status check.
The recurrence became part of the reaction. Teknium said GitHub went down again for another hour Teknium's follow-up, and NousResearch attributed a separate failure to the current outage NousResearch's reply. iannuttall posted another terse reaction iannuttall's reaction, badlogicgames followed with “another one” badlogicgames' follow-up, and skalskip92 said they were losing their mind over the day's failures skalskip92's reply.
Failure surface
The incident affected eight service categories in GitHub's final incident record: Git Operations, Webhooks, API Requests, Issues, Pull Requests, Actions, Pages, and Copilot.
GitHub also reported:
- About 20% errors across web experiences and API traffic.
- About 50% errors for archive downloads and raw repository content downloads.
- Impact to SAML and OIDC authentication, SCIM, and Team Sync.
- Copilot authentication failures that persisted after other services began recovering.
The symptoms mapped directly onto the software delivery loop. A repository page showed “Cannot retrieve latest commit,” Teknium identified CI as the failing surface Teknium's CI reply, and rauchg said his team was stuck because of GitHub rauchg's reply.
Agent workflows
The failure reached products built around GitHub as an agent back end. A Cursor notification said GitHub degradation was affecting Automations, Cloud Agents, and Codebase Cursor's outage notice.
Doodlestein said he sometimes makes more than 1,000 commits per day doodlestein's reply. Eito_Miyamura first posted “Time to touch grass” Eito_Miyamura's post, then said he used Claude Code Cloud almost exclusively and had stopped opening the CLI Eito_Miyamura's cloud-agent post. Those workflows make repository access, commit lookup, pull requests, and CI part of the agent runtime rather than a separate developer tool.
Recovery and root cause
The 16:59 mitigation did not end the incident cleanly. Git Operations degraded again at 17:30, Issues at 17:36, and API Requests at 18:48 before returning to normal at 19:01, according to GitHub's incident record.
At 20:08, GitHub was still investigating sporadic authentication failures. At 20:45, it said Copilot authentication failures remained in some applications, although GitHub CLI and GitHub App usage were unaffected. The incident was marked resolved at 21:15 UTC.
GitHub said it had identified the “problematic component” and taken corrective actions, but did not name that component in the incident updates. The record says a detailed root-cause analysis will be shared later. No cause is established in the incident report.
Reliability signals
The August outage arrived after months of public reliability complaints. In an April analysis, Gergely Orosz reported third-party uptime measurements as low as 86%, or “zero nines,” and wrote that GitHub leadership blamed a roughly 3.5x increase in service load for the degradation: The Pragmatic Engineer's analysis.
The chart in Orosz's analysis showed monthly pull requests merged rising from 25 million to 90 million, monthly commits from 389 million to 1.4 billion, and new repositories from 6.5 million to 20 million over two years Gergely Orosz's load chart. Orosz also argued that older architectural decisions were biting harder as reliability problems persisted Gergely Orosz's reliability post.
That load explanation predates the Aug. 17 incident. GitHub's current status record reports mitigations and a pending RCA, without connecting this outage to AI traffic or naming an infrastructure failure.
Alternatives
Cursor announced Origin on Aug. 17 as an early beta for paid plans. Its official changelog describes hosted repositories, pull requests, code browsing, GitHub synchronization, and agent features in the same workspace.
Origin's GitHub boundary is explicit:
- Cursor-hosted repositories can be created, cloned, and pushed through the Origin CLI.
- Selected GitHub repositories can be synced into Origin and updated in real time.
- Pushes for synced repositories continue going to GitHub, which remains the source of truth.
- Pull-request comments, replies, reviews, and merges sync between Cursor and GitHub.
- Vercel, Depot, and Buildkite integrations are available; Depot and Buildkite can run existing GitHub Actions workflows.
NickADobos called the timing notable because Origin launched during the outage NickADobos's post. rauchg said Origin could host repositories and deploy to Vercel through the service rauchg's announcement, while Gergely Orosz wrote that GitHub instability made alternatives more interesting Gergely Orosz's follow-up.
Cursor was not the only fallback appearing in the discussion. sqs said Amp could now host Git repositories sqs's announcement, Doodlestein's dsr reuses GitHub Actions workflow files for local builds and releases dsr project, and imbue_ai pointed to self-hostable Forgejo imbue_ai's Forgejo suggestion. Kunchenguid argued that these efforts mostly target paid source control while leaving the open-source ecosystem without a dedicated replacement kunchenguid's argument.