Actions delays in starting runs

What to do

• Check whether you use GitHub Actions. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 38m it lasted.

  Anything that failed between 2026-08-24 13:56 UTC and 2026-08-24 14:34 UTC may need a replay.

• Subscribe to GitHub's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=github works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from GitHub 4

1. investigatingAug 24, 2026, 1:56 PM UTC

   We are investigating reports of degraded performance for Actions

   provider

2. investigatingAug 24, 2026, 2:22 PM UTC

   Failures while queuing and running Actions jobs for a subset of customers are now resolving. We are monitoring for full recovery.

   provider

3. monitoringAug 24, 2026, 2:26 PM UTC

   The degradation affecting Actions has been mitigated. We are monitoring to ensure stability.

   provider

4. resolvedAug 24, 2026, 2:34 PM UTC

   On August 24, 2026, between 13:33 UTC and 14:04 UTC, 3.8% of Actions runs experienced start delays over 5 minutes with 1.25% of Actions runs failing outright. The incident was caused by a disk failure on a node hosting one of many service instances responsible for processing runner assignment events. Typically, pods on unhealthy nodes are removed and replaced automatically without impact. In this case, although the node was severely degraded and unable to perform disk operations, it continued sending healthy signals, preventing the system from immediately moving its work elsewhere. During this period, events assigned to the affected component accumulated until an automatic rebalance redirected processing to healthy components at 13:54 UTC. The queue backlog was cleared at 14:00 UTC, and processing returned to normal by 14:04 UTC. To prevent a recurrence, we are improving detection and automated remediation for unhealthy nodes that aren’t fully offline. We are also strengthening application-level resiliency, so stalled consumers are automatically removed quickly and their work reassigned without waiting for the affected node to recover.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.