The August 6, 2026 GitHub Actions Outage: Queued Jobs, Throttled Webhooks, Impact Lasting 10 Hours
Introduction
On August 6, 2026, GitHub opened an incident for degraded Actions performance at 15:22 UTC. Within about twenty minutes, Actions availability was listed as degraded, workflow runs were failing to start or failing partway through, and the Actions REST API was returning errors. Pages was pulled into the same incident shortly afterwards. The status page marked Actions and Pages as mitigated at 00:05 UTC on August 7, and closed the incident at 02:04 UTC.
GitHub has not published a root cause analysis as of this writing. What the status updates do show is a multi-hour recovery through constrained capacity, throttled webhooks, invalid job assignment, and self-hosted runner problems - followed by cleanup work that continued after the incident was marked resolved.
- Introduction
- Methodology and Coverage
- Timeline of the Outage
- The Impact and What Is Still Unknown
- The Recovery Tail
- GitHub Actions - A Pattern of Failure
- Conclusion
- FAQ
Methodology and Coverage
This write-up is based on GitHub's own incident page, with customer-facing detail from GitHub's community incident thread. Resolved timestamps below are status page state. IncidentHub monitors GitHub status updates in real time and the aggregate charts in this post are based on that data.
Timeline of the Outage
| UTC | Event |
|---|---|
| Aug 6 15:22 | First public investigating post - degraded performance for Actions |
| 15:41 | Actions availability degraded |
| 15:45 | First concrete failure modes - workflows failing to start or mid-run, Actions REST API errors, unexpected rate limiting. Engineers said they had identified the source of the disruption |
| 15:53 | Pages pulled in - degraded performance |
| 16:19 | Pages briefly marked operating normally |
| 16:27 | Pages degraded again. First indication that other services are also affected - Actions API errors, migrations with GitHub Enterprise Importer |
| 16:33 | Actions and Pages both listed as degraded availability |
| 17:02 | Mitigations underway; further fix rolling out - Actions API errors and Importer migration failures continue |
| 17:40 | Impact widens further - Copilot code review, Copilot coding agent, hosted runners, Importer migrations, delayed webhook deliveries |
| 18:11 | Self-hosted runners enter the picture - registration errors or rate limiting |
| 18:46 | Hosted-runner jobs particularly hard hit under constrained capacity. Recovery "taking longer than we expected" |
| 19:43 | Still constrained - jobs may delay or fail while recovering gradually |
| 20:34 | First hard recovery numbers - webhooks at about 15% throughput; queued-job success about 65%, up from a low of 30 to 40%. Remaining impact narrowed to runners stuck retrying unavailable jobs |
| 21:30 | Invalid job assignment identified - both hosted and self-hosted runners affected. Importer migrations paused to support mitigation |
| 22:18 | Starting workflow success rates at 97%. Webhook triggers still throttled |
| 23:13 | Running-workflow success rates at 99%. Hosted-runner assignment queues nearly burned down; webhook throughput being restored gradually |
| Aug 7 00:01 | Queues drained; webhook-triggered Actions back to full throughput; Pages, Copilot code review, and Copilot coding agent showing recovery. Importer migrations still paused |
| 00:05 | Actions and Pages called mitigated - monitoring for stability |
| 00:59 | Recovery tail opens - some Actions Runner Controller (ARC) runners taking longer than expected to recover |
| 02:03 | Customer cleanup left after mitigation - idle ARC pods need delete or redeploy; some push and pull request trigger events were not processed and cannot be replayed |
| 02:04 | Incident resolved. Detailed root cause analysis promised when available |
Impact window (status page): Aug 6 15:22 UTC to Aug 7 02:04 UTC (about 10 h 42 m from first investigating post to resolve).
Mitigation called: Aug 7 00:05 UTC (about 8 h 43 m after the first investigating post).
Note: A separate Pages incident ("Incident with Pages - Deployment Lag") was opened at 15:03 UTC and marked resolved at 16:22 UTC on August 6. The Actions incident above still listed Pages as degraded after that separate incident closed.
Source: GitHub Status, Incident with Actions, August 6-7, 2026
The Impact and What Is Still Unknown
GitHub named Actions and Pages as the affected components on the incident. The live updates also named Copilot code review, Copilot coding agent, hosted runners, self-hosted runners, webhook deliveries, and migrations using GitHub Enterprise Importer.
What customers saw, in GitHub's words:
- Workflow runs failing to start, failing partway through, staying queued, or timing out.
- Actions REST API errors and unexpected rate limiting.
- Webhook throughput cut during recovery - down to about 15% at one point - so many push and pull request events did not start workflows.
- Runners assigned jobs that were no longer valid, and runners stuck retrying unavailable jobs.
- Self-hosted runner registration errors or rate limiting.
- Pages degraded availability and performance.
- GitHub Enterprise Importer migrations failed, then paused as a mitigation.
At 15:45 UTC, GitHub said engineers had identified the source of the disruption although the source was not specified. The closing post promised a detailed root cause analysis when available. As of this writing, that analysis has not been posted on the incident page. We will update this article when it is published.
Other services which depend on Actions failed to push production deployments:
- Commercetools reported a failure in pushing deployments to production because of the Actions outage.
- WordPress VIP reported deployment issues arising from the same Actions outage.
The Recovery Tail
The status page called mitigation at 00:05 UTC and resolved the incident at 02:04 UTC. Customer reports in the community incident thread continued after both timestamps.
GitHub's own 02:03 UTC update described leftover work as follows:
- Some Actions Runner Controller (ARC) runner pods were stuck idle. The recommended fix was to delete those pods with
kubectl, or redeploy the Actions Runner Controller application, after which ARC would create replacement runners. GitHub said later releases of Actions Runner and Actions Runner Controller would add automatic recovery for this case. - Some workflow-triggering events, including push and pull request events, were not processed during the incident and cannot be replayed automatically. Customers may need to push a new commit, update the pull request, or re-run the workflow.
In the community thread, several users reported workflow runs stuck in Queued after the incident was marked resolved, with cancel and force-cancel failing. For ARC specifically, GitHub's advice was pod deletion or redeploy.
GitHub Actions - A Pattern of Failure
Eight days earlier, on July 29, 2026, GitHub published a postmortem for a shorter Actions incident: from 14:51 to 15:28 UTC, an under-provisioned internal Actions service at a single infrastructure site ran out of memory under load, Actions API requests that waited synchronously on that service timed out, and about 2% of workflows were delayed. That incident had a named cause and a named mitigation - scale out the runner-administration service and raise the replica count.
GitHub Actions outages have seen a trend towards longer durations over the course of 2026.
IncidentHub's earlier reporting put Actions at the center of GitHub's reliability problem. In our May 2025 to April 2026 GitHub reliability report, Actions was the most affected service, with 57 outages in that window. In the H1 2026 reliability report, Actions remained the worst affected GitHub component, with 37 recorded incidents in the first half of the year.
Between Jan 1, 2026 and August 7, 2026, GitHub Actions had 48 recorded outages, with 26 of them major.
Note: numbers for August are till 7th August, 2026 only.
The trend for major outages is moving upward, although overall Actions related outages dipped in June 2026 and then increased in July 2026.
Note: numbers for August are till 7th August, 2026 only.
Conclusion
GitHub's August 6 Actions incident ran from 15:22 UTC to a resolve post at 02:04 UTC on August 7. Pages, Copilot code review, Copilot coding agent, hosted and self-hosted runners, webhooks, and GitHub Enterprise Importer migrations were named along the way as being affected. Recovery metrics improved as the incident progressed, mitigation was called just after midnight UTC, and the closing update still left customers with manual ARC cleanup and unreplayable trigger events.
As of this writing, GitHub has not published the root cause. Until that analysis appears, the durable facts are the ones on the incident page and in the customer reports that continued after it closed.
FAQ
What caused the August 6, 2026 GitHub Actions outage?
GitHub has not published a root cause analysis as of this writing. At 15:45 UTC on August 6, the status page said engineers had identified the source of the disruption, but the public updates never named it. The resolve post said a detailed root cause analysis would be shared when available.
How long did the GitHub outage last?
On the status page, the incident opened at 15:22 UTC on August 6 and was marked resolved at 02:04 UTC on August 7, about 10 hours 42 minutes later. Actions and Pages were called mitigated at 00:05 UTC on August 7. Customer reports of stuck queued workflows and ARC recovery problems continued after the resolve timestamp.
Which GitHub services were affected?
The incident listed Actions and Pages as affected components. Live updates also named Copilot code review, Copilot coding agent, hosted runners, self-hosted runners, webhook deliveries, and migrations using GitHub Enterprise Importer.
Were workflow triggers lost during the incident?
Yes, according to GitHub's 02:03 UTC update. Some workflow-triggering events, including push and pull request events, were not processed during the incident and cannot be replayed automatically. GitHub said customers may need to push a new commit, update the pull request, or manually re-run the workflow.
How does this compare to the July 29, 2026 Actions incident?
The July 29 incident was shorter - 14:51 to 15:28 UTC - and GitHub published a cause: an under-provisioned internal Actions service at one site ran out of memory, delaying about 2% of workflows. The August 6 incident lasted much longer, touched more products in the updates, and closed without a public root cause.
IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by GitHub or any of the services and vendors mentioned in this article.
This article was first published on the IncidentHub blog.
You might also like: