April 2026 Availability Report: Ten Incidents, Broad Service Impact
GitHub experienced ten incidents in April that degraded performance across its services. The month included two major events on April 23 and April 27, which were detailed in a separate blog post, as well as steps to add more granular reporting to the status page. The incidents below cover the full range of disruptions, from brief connectivity blips to multi-hour outages affecting search, Copilot, and core Git operations.
Code Search Fully Unavailable for Over Two Hours
April 1, 14:40–17:00 UTC (full outage), until 23:45 UTC (stale results)
GitHub’s code search service was completely unavailable between 14:40 and 17:00 UTC, with 100% of search queries failing. Service recovered in a degraded state by 17:00 UTC, but results did not reflect repository changes made after approximately 07:00 UTC that day. Full indexing caught up by 23:45 UTC.
A routine infrastructure upgrade to the messaging system supporting code search was applied too aggressively, causing a coordination failure between internal services. This halted search indexing and caused results to go stale. While the team worked to recover the messaging infrastructure, an unintended service deployment cleared internal routing state, escalating the staleness into a complete outage.
Recovery involved a controlled restart of the messaging infrastructure to reestablish coordination, followed by a reset of the search index to a point before the disruption. No repository data was lost—the search index is a secondary index derived from Git repositories, which were unaffected.
Planned improvements include more gradual upgrades with better health checks, deployment safeguards to prevent unintended changes during active incidents, faster recovery tooling, and better traffic isolation to prevent cascading impact from unexpected traffic spikes.
Brief Audit Log Outage from Failed Credential Rotation
April 1, 15:34–16:02 UTC
The audit log service lost connectivity to its backing data store due to a failed credential rotation. During the 28-minute window, audit log history was unavailable via both the API and web UI, resulting in 5xx errors for 4,297 API actors and 127 github.com users. Events created during this window were delayed by up to 29 minutes, but no audit log events were lost. Customers using GitHub Enterprise Cloud with data residency were not impacted.
Alerting fired six minutes after onset at 15:40 UTC, and the issue was resolved by recycling the affected environment, restoring full service by 16:02 UTC. Follow-up actions included strengthening the credential rotation process and enhancing monitoring, including making paging thresholds more sensitive.
Copilot Coding Agent Suffers Repeated Rate Limit Failures
April 9, 09:05–19:05 UTC and 16:05–20:36 UTC
The Copilot coding agent service was degraded across two incidents on April 9, with users experiencing significant delays starting new agent sessions. Approximately 84% of new session requests were delayed across four separate outage waves, with queue wait times peaking at 54 minutes versus a normal baseline of 15–40 seconds. The average error rate was 83.9%, peaking at 97.5%. Roughly 22,700 workflow creations were delayed or failed.
A bug in rate limiting logic incorrectly applied a rate limit globally across all users rather than scoping it to the individual installation that triggered the limit. A contributing factor was a surge in API traffic from a client update that increased requests to an internal endpoint by 3–4x, accelerating rate limit exhaustion. The second incident was also caused by an internal service exceeding API rate limits, compounded by a caching bug that persisted the rate-limited state beyond the actual limit window.
The team detected the issue within 15 minutes and mitigated it by disabling the faulty rate limiting cache via feature flag and updating the service to use per-installation credentials for API calls. Service fully recovered by 20:36 UTC. Automated monitoring has been added to detect this failure mode proactively, and fixes have been deployed to reduce unnecessary API traffic through caching improvements.
GitHub Pages DNS Record Deletion Causes Error Spike
April 13, 18:53–20:35 UTC
The GitHub Pages service experienced elevated error rates, averaging 10.58% and peaking at 12.77%, resulting in approximately 17.5 million failed HTTP 500 requests. An automated DNS management tool erroneously deleted a DNS record for a GitHub Pages backend storage host after its upstream data source intermittently failed to return the record, causing the tool to treat it as stale and remove it. As cached copies expired, servers could no longer reach the affected storage host.
Once identified, the team re-created the missing DNS record, returning service to normal by 20:30 UTC. Detection took approximately 53 minutes due to the gradual nature of the error increase and a gap in alerting. Three improvements are planned: availability-zone-tolerant routing for failover to healthy hosts, safeguards to prevent automated deletion of DNS records owned by other systems, and improved logging and alerting for DNS resolution failures.
VS Code Connections to Codespaces Fail Intermittently
April 16, 09:30–17:15 UTC
Users experienced failures connecting to GitHub Codespaces via the VS Code editor, with approximately 40% of codespace start operations failing. SSH connections were not impacted. The root cause was failures in an upstream service that prevented the VS Code Server from being retrieved during startup.
Impact was mitigated through a workaround using an alternative download path when the primary endpoint is degraded, while coordinating with the upstream dependency team on the root cause. Improvements are focused on strengthening the fallback mechanism and streamlining deployment processes for similar changes.
Serialization Error Halts Code Scanning and Project Board Updates
April 20–21, 10:28 UTC–15:04 UTC (boards until 05:04 UTC April 21)
Degraded service affected code scanning default setup, code quality, and project boards. During this period, code scanning default setup and code quality analyses were not triggered on newly opened pull requests, and newly created issues were not appearing on project boards. The cause was a serialization error preventing proper triggering of these services.
The issue was identified within ~40 minutes. A fix was deployed to restore event publishing for code scanning and code quality, followed by an additional code change to update project board event consumers and a reindex of affected items. Preventative work includes strengthening schema validations and improving monitoring for drops in publishing on critical topics, plus auditing other parts of the system for similar limitations.
Database Connectivity Issue Takes Down Copilot Chat
April 22, 15:16–19:18 UTC
Users experienced errors when interacting with Copilot Chat on github.com and Copilot Cloud Agent. During this time, Copilot Chat and Cloud Agent were unusable, and Copilot Memory (in preview) was unavailable to agent sessions. An infrastructure configuration change caused connectivity issues with databases.
The team identified the cause and restored database connectivity. Copilot Chat and Cloud Agent for github.com recovered by 18:16 UTC, with remaining regional deployments restored incrementally and full resolution at 19:18 UTC. Steps have been taken to prevent similar infrastructure changes from causing these kinds of database operational failures.
DNS Degradation in One Datacenter Cascades Across Services
April 23, 16:03–17:30 UTC
Users experienced elevated error rates and degraded performance across GitHub Copilot, Webhooks, Git Operations, GitHub Actions, Migrations, and Deployments. Approximately 5–7% of overall traffic was affected. Impact details: ~7% of AI model requests for Copilot failed, ~10% of Copilot cloud agent sessions were affected, ~9% of Copilot Insights requests errored, ~0.35% of webhook API requests errored at peak with up to 10% seeing latency over 3 seconds, Git Operations averaged 1.25% errors, Actions saw workflow status update delays of up to ~8 seconds, and 0.88% of active migrations failed. Deployments were temporarily blocked.
DNS infrastructure in one datacenter entered a degraded state, intermittently failing to resolve service addresses. The root cause was a recently introduced traffic-balancing mechanism, rolled out progressively, which caused DNS resolvers to fail under a specific load pattern. Existing DNS caching provided partial protection, limiting overall impact to 5–7% of traffic.
An initial configuration rollback did not resolve the issue. A restart of the affected DNS infrastructure brought services back within minutes, with all normal by 17:30 UTC. No data was lost. Ongoing improvements include enhancing DNS infrastructure resilience, safer rollout and validation in dedicated environments, faster automated detection and self-healing, and reviewing service dependencies to reduce blast radius.
Search Overwhelmed by Distributed Scraping Traffic
April 27, 16:15–22:46 UTC
GitHub search services experienced degraded connectivity due to saturation of the load balancing tier in front of the search infrastructure. This caused intermittent failures for services relying on search data, including Issues, Pull Requests, Projects, Repositories, Actions, Package Registry, and Dependabot Alerts. Between 16:15 and 18:00 UTC, services saw up to 65% of searches timing out or returning errors.
The saturation was caused by a large influx of anonymous distributed scraping traffic crafted to avoid public API rate limits. This traffic made up 30% of the day’s total search traffic, concentrated within a four-hour period, and originated from over 600,000 unique IP addresses with matching actor information. Existing monitoring did not classify the increased scraping as a risk.
Mitigation focused on relieving pressure from load balancers while scaling the load balancing tier, blocking anomalous traffic, and applying tuning. To prevent recurrence, the load balancer tier has been scaled, connection handling and re-use optimized, and new monitors and controls added to restrict anonymous traffic and mitigate impact to registered users.
