Cases2 cases

1 to 2 of 2

1. IL-0471 GitHub Actions runs failed or sat queued for 9 hours after a routine deployment's pod replacement saturated capacity

   GitHub2026

   Symptoms

   From 15:05 UTC on 6 August 2026 GitHub Actions workflow runs failed to start, failed partway through or stayed queued for a long time, on both GitHub-hosted and self-hosted runners. Some requests to the Actions REST API returned errors, and some customers saw unexpected rate limiting in their workflows.

   High error rateHigh latency

   Trigger

   A routine deployment to an internal Actions service that processes events and generates Actions jobs replaced pods, and the remaining capacity became saturated.

   Root cause

   Capacity exhaustion

   Component

   CI system

   Contributing factor

   No headroomExcessive blast radiusHarmful manual action

   Remediation

   • Expanded capacity of the affected services
   • Throttled incoming webhook-triggered work
   • Increased processing capacity for the backlog of affected events
   • Deployed changes that stopped runners from repeatedly trying to acquire invalid jobs
   • Deployed a fix for self-hosted runners that were not picking up jobs and enabled it incrementally
   • Paused migrations with GitHub Enterprise Importer
   • Restored webhook-triggered Actions workflows to full throughput
   • Rolled back the mitigation that left some ARC runners offline, and recovered those runners by hand
   • Shared CLI and UI steps for customers to clear jobs that could not be retried or canceled

   Action items

   • Improve deployment and capacity safeguards for the affected services
   • Strengthen monitoring for the conditions that preceded the incident
   • Improve the resiliency and recovery of queued work and runner assignment
   • Add automatic recovery for self-hosted runners in upcoming Runner and ARC releases
   • Reduce the risk of cascading failures and speed up recovery during large Actions disruptions

   View case
2. IL-0385 GitHub MySQL read replicas hit a semaphore deadlock during a schema migration's table rename and kept crash-recovering

   GitHub2021

   Symptoms

   On 27 November 2021 at 20:40 UTC, a significant part of GitHub's MySQL read replicas entered a semaphore deadlock while a schema migration on a large MySQL table ran its final step, the rename that moves the updated table into place. Core GitHub services, including GitHub Actions, API Requests, Codespaces, Git Operations, Issues, GitHub Packages, GitHub Pages, Pull Requests and Webhooks, became degraded.

   Lock contention or deadlockDatabase overload

   Trigger

   The final rename step of a schema migration on a large MySQL table. Schema migrations are a common task at GitHub and often take weeks to complete.

   Root cause

   Software defect

   Component

   DatabaseSchema migration

   Contributing factor

   No headroomNo staged rollout

   Remediation

   • Promoted every healthy internal replica into the production path to add read capacity
   • Removed production traffic from the broken replicas until each had processed the table rename
   • Moved the recovered replicas back into production to restore capacity

   Action items

   • Continue functional partitioning so migrations can run in canary mode on a single shard
   • Update internal procedures to increase how much each cluster is over-provisioned
   • Pause schema migrations until it is known how to safeguard against this failure
   • Keep investigating the specific failure scenario
   • Test the migration tooling and classify ways to improve it for this kind of scenario

   View case

By root cause2