The August 6, 2026 GitHub Actions Outage: Queued Jobs, Throttled Webhooks, Impact Lasting 10 Hours
Last updated on August 12, 2026.
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.
What the live updates showed at the time was 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. GitHub added a root cause analysis to the incident page on 11 August 2026, appended to the 7 August resolve post rather than as a separate update.
- Introduction
- Methodology and Coverage
- Timeline of the Outage
- Impact and Root Cause
- Preventing Future Actions Outages
- 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. The RCA published later notes that "A mitigation deployed during the incident inadvertently affected these runners, causing some to remain offline until they were manually recovered." |
| 02:04 | Incident resolved. Detailed root cause analysis promised when available, which was subsequently added to the incident report on Aug 11 |
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). Although the RCA notes that the impact window ended at 00:14 UTC, the overall impact continued as is evident from the live updates published previously until 02:04.
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
Impact and Root Cause
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 public updates did not name it. On 11 August 2026, GitHub published a root cause analysis on the incident page. It sits on the 7 August resolve post, not as a separately timestamped update.
Impact window (RCA): 15:05–00:14 UTC on August 6–7. GitHub-hosted and self-hosted runners were both affected. At peak, 71% of workflow runs saw infrastructure failures, and 75% of the remainder were delayed by more than 5 minutes.
Note: The RCA's impact window starts at 15:05 UTC, which is 17 minutes before the first public investigating post at 15:22 UTC. The status page marked the incident resolved at 02:04 UTC on August 7.
The failure had two stages. A routine deployment to an internal Actions service - the one that processes events and generates jobs - exposed an existing capacity and concurrency weakness. As pods were replaced, remaining capacity saturated, services crashed, and the impact cascaded across multiple clusters and downstream services. GitHub said those services recovered at 17:00 UTC after expanding capacity, throttling webhook-triggered work, and raising processing capacity for the backlog.
The longer tail came next. Work piled up in the job-assignment path, and a latent bug let runners take jobs that were no longer valid and then retry them indefinitely instead of picking up valid work. GitHub mitigated that by stopping repeated attempts on invalid jobs, which let the queues drain.
Some cleanup was still customer-visible after that. A mitigation deployed during the incident inadvertently left some Actions Runner Controller (ARC) runners offline until manually recovered; GitHub rolled that change back and said automatic recovery is coming in upcoming Runner and ARC releases. Some jobs created during the incident were left stuck and could not be retried or cancelled; GitHub pointed customers to CLI and UI workarounds in the community thread. GitHub's 02:03 UTC update also said some push and pull request trigger 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. Reports in the same thread show the gap between resolve and recovery: users had workflow runs stuck in Queued after the incident was marked resolved, with cancel and force-cancel failing.
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.
Preventing Future Actions Outages
GitHub noted in their RCA that they are taking measures to prevent such occurrences in the future:
- Improvements to deployment and capacity safeguards for the affected services
- Strengthening monitoring for the conditions preceding the incident
- Improving the resiliency and recovery of queued work and runner assignments
- Adding automatic recovery for self-hosted runners affected by similar failure conditions.
They also note that they are undertaking measures to reduce the risk of cascading failures and accelerate recovery during large-scale Actions disruptions.
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, and mitigation was called just after midnight UTC.
GitHub published the root cause on 11 August 2026, four days after the incident closed - a routine deployment that exposed a capacity weakness, then a latent job-assignment bug that kept runners retrying invalid work. The RCA said a mitigation deployed during the incident had inadvertently left some ARC runners offline until manually recovered; GitHub rolled that change back. Customer reports of unreplayable triggers, stuck jobs, and workflows still Queued after resolve still matter: status page state and pipeline state are not the same thing.
FAQ
What caused the August 6, 2026 GitHub Actions outage?
A routine deployment to an internal Actions service exposed a capacity and concurrency weakness; as pods were replaced, remaining capacity saturated and the impact cascaded. A latent bug in job assignment then left runners retrying invalid jobs. GitHub published the analysis on 11 August 2026, appended to the 7 August resolve post. At peak, 71% of workflow runs saw infrastructure failures and 75% of the remainder were delayed by more than 5 minutes.
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's report named the 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 its root cause analysis did not appear until 11 August.
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: