GitHub’s May Availability Report: Infrastructure Shifts and Incident Breakdown

GitHub has published its monthly availability report for May 2026, detailing nine incidents that caused degraded performance across its services. The report also provides an update on the company’s ongoing infrastructure overhaul, which is prioritizing elastic capacity on Azure and the decomposition of its monolithic architecture into isolated services.

Infrastructure Progress and Strategic Direction

According to the report, GitHub is now routing 40% of monolith traffic from Azure, a significant jump from the 8% reported in February. Git traffic is at 30% and repository replication sits at 99%. The company states it has more than doubled its effective capacity in the last four months, driven by a surge in traffic from AI-assisted and agentic development workflows.

A key part of the resilience strategy involves isolating the primary database cluster. The new users service is fully cut over and reportedly handles double the traffic at a substantially lower database cost. Additionally, the rollout of stateless authentication tokens is underway, which is designed to eliminate per-request database lookups that previously amplified pressure during traffic spikes. GitHub reiterates its guiding principle as availability, then capacity, then features.

May 4: Widespread Service Disruption from a Database Migration

A routine online schema migration on a large, heavily-accessed table triggered a 55-minute disruption on May 4, starting at 15:45 UTC. As traffic ramped up toward the weekly peak, the combined load saturated database connection capacity, causing query contention on a primary database. This led to cascading timeouts across services dependent on it.

Pull requests were the most affected, statused Red, with issues, actions, webhooks, and Git operations also experiencing elevated latency. At peak, approximately 1.3% of requests returned a 5xx response. The migration was paused after detection, with full resolution coming roughly 30 minutes after initial mitigation. GitHub is implementing dynamic throttling for migrations, automated circuit breakers based on latency thresholds, and enhanced monitoring to prevent a recurrence.

May 5-6: Connected Actions Outages

Two related incidents on consecutive days degraded GitHub Actions hosted runners in the East US region. The May 5 event, lasting 3 hours and 49 minutes, saw approximately 13.5% of standard runner requests fail due to a scale-up operation hitting an internal rate limit when pulling VM images. The failure also impacted Copilot code review, with around 8,500 requests timing out.

Remediation work from that incident introduced a configuration issue that triggered the May 6 outage, lasting 2 hours and 25 minutes. That day, 17.1% of jobs requesting a standard Ubuntu runner failed after abnormal configuration data blocked new allocations. The data was removed, allowing pools to recover. GitHub is updating its throttling behavior and allocation filter logic to be resilient to abnormal data shapes.

May 6-7: Copilot and Pull Request Specifics

Several incidents were isolated to specific features. On May 6, users were briefly unable to start or view Copilot cloud agent sessions for 38 minutes due to a configuration change that removed the service’s ingress path. Later that day, a separate 3-hour and 39-minute incident prevented the creation of new pull request review threads. The cause was a 32-bit integer key reaching its maximum value in a Vitess lookup table, which was not migrated to a 64-bit key alongside the primary table.

On May 7, a 1-hour and 54-minute incident saw new Copilot coding agent sessions triggered by pull requests fail to start. This was a secondary effect of a large database migration run as follow-up recovery from the previous day's pull request incident, which caused replication delays. Safeguards correctly slowed writes to the cluster, but this temporarily delayed the background processing responsible for sending events to Copilot agents.

May 15, 26, and 28: From Failover to Provider Issues

A planned failover of supporting infrastructure for Actions on May 15 caused workflow runs to fail for 35 minutes. An automated service discovery update did not propagate correctly, misrouting traffic and causing timeouts. At peak, 42% of Actions runs failed, which also impacted Pages and Copilot. GitHub is implementing failover guardrails to validate service discovery state before completing such operations.

On May 26, an outage lasting 2 hours and 21 minutes prevented all newly queued Actions runs from starting. The automated account review system had incorrectly suspended the service account used by GitHub Actions. While a small number of issues, pull requests, and comments were marked as hidden during the incident, no data was lost and all content was restored. GitHub has added an allowlist of service accounts that cannot be suspended by automated systems.

The final incident of the month, on May 28, was an upstream issue. The Copilot service was degraded for 1 hour and 40 minutes due to problems with an upstream provider's Responses API affecting specific GPT models (GPT-5.2 through GPT-5.5). GitHub mitigated the issue by shifting traffic away from the affected models while the provider deployed a fix.