GitHub logged 10 incidents in April

GitHub said on May 14 that it logged 10 incidents in April 2026 that caused degraded performance across its services, according to the company’s monthly availability report. The incidents affected products including code search, audit logs, GitHub Actions, search-dependent services and APIs, based on GitHub’s report and status history. (github.blog) The report followed two separate GitHub blog posts in April that detailed major incidents on April 23 and April 27, which the company said it published as part of a broader push for more transparency. GitHub said on April 17 that it had also changed its status page to add a “Degraded Performance” classification and publish per-service uptime over the last 90 days. (github.blog) ### Which April failures did GitHub describe in the most detail? April 1 accounted for two of the incidents described near the top of GitHub’s report. GitHub said its code search service was fully unavailable between 14:40 UTC and 17:00 UTC, causing 100% of search queries to fail, before returning in a degraded state with stale results and fully recovering by 23:45 UTC. GitHub attributed that outage to an automated infrastructure change during a messaging-system upgrade, followed by an unintended deployment that cleared internal routing state. April 1 also brought a separate audit-log disruption. GitHub said its audit log service lost connectivity to its backing data store during a failed credential rotation, making audit log history unavailable in the API and web interface for 28 minutes. (github.blog) The company said that window generated 5xx errors for 4,297 API actors and 127 github.com users, while events created during the disruption were delayed by as much as 29 minutes. ### What happened in the late-April incidents that drew separate updates? April 27 was the date of a search-related incident that GitHub said affected multiple products that rely on search data. According to GitHub’s status history, degraded connectivity in the search stack led to intermittent failures in Issues, Pull Requests, Projects, Repositories, Actions, Package Registry and Dependabot Alerts, with some search targets seeing as much as 65% of requests time out or return errors between 16:15 UTC and 18:00 UTC. (github.blog) GitHub said the saturation was caused by a large influx of anonymous distributed scraping traffic designed to avoid public API rate limits. April 28 brought a separate GitHub Actions problem. (github.blog) GitHub’s status page said jobs using Standard Ubuntu 22 and Ubuntu 24 hosted runners experienced run-start delays from 12:41 UTC to 17:09 UTC, and about 8% of those jobs saw delays longer than five minutes or failures. GitHub said larger runners and self-hosted runners were not affected, and traced the problem to a performance regression in the VM reimage process. ### Why is GitHub publishing monthly availability reports now? Jakub Oleksy, writing on GitHub’s blog, said the April report was part of a transparency effort that also included separate write-ups for major incidents at the end of the month. On April 17, Oleksy said GitHub was adding a new “Degraded Performance” state to sit alongside “Partial Outage” and “Major Outage,” arguing that the older classifications could overstate the degree of service loss when a product was impaired but still operating. (githubstatus.com) The April 17 post also said GitHub had begun publishing 90-day uptime percentages for each service on its status page. GitHub said those percentages are weighted by incident severity, with degraded performance counting as 0% downtime, partial outage counting at 30% of duration and major outage counting at 100% of duration. (githubstatus.com) ### What has GitHub said about the broader reliability problem? Vlad Fedorov, a GitHub executive, said on April 28 that the company had started a plan in October 2025 to increase capacity by 10 times, but by February 2026 concluded it needed to design for 30 times current scale. Fedorov said “agentic development workflows” had accelerated sharply since the second half of December 2025 and increased repository creation, pull-request activity, API usage, automation and large-repository workloads. (github.blog) April 28’s company update said GitHub was reducing unnecessary work, improving caching, isolating critical services, removing single points of failure and moving performance-sensitive paths out of its Ruby monolith into Go. (github.blog) Fedorov said the company had also used its migration to Azure to add compute capacity and was working to limit blast radius across services such as git and GitHub Actions. ### Where can users track the next disclosures? GitHub’s public status pages continued to post new incidents in May, including a May 15 disruption that the company said made GitHub.com unavailable for a subset of customers for about 15 minutes after a spike in traffic. (github.blog) GitHub said on April 17 that its status page would carry more granular service data and per-service uptime, while the May 14 availability report said monthly recaps would continue through the GitHub blog. (githubstatus.com)