GitHub acknowledges availability issues

GitHub said on April 28 it is still repairing service problems after two recent incidents, including incomplete pull request listings tied to an April 27 search failure. (github.blog) (githubstatus.com) Chief technology officer Vlad Fedorov said GitHub started a plan in October 2025 to raise capacity by 10 times, then concluded by February 2026 that it needed to design for 30 times current scale. (github.blog) Fedorov linked that shift to a surge since the second half of December 2025 in “agentic” development workflows, with repository creation, pull request activity, application programming interface usage, automation, and large-repository workloads all rising quickly. (github.blog) GitHub said a single pull request can hit Git storage, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, application programming interfaces, background jobs, caches, and databases. (github.blog) That matters because GitHub has already spent months dealing with repeated instability. On March 11, the company said three major incidents had hit on February 2, February 9, and March 5. (github.blog) In its February 2026 availability report, GitHub said it had six incidents that month. In its March 2026 report, it said four incidents hit in March. (github.blog 1) (github.blog 2) One March 3 incident lasted 1 hour and 10 minutes and pushed github.com request failures to about 40%, while about 43% of GitHub application programming interface requests failed. (github.blog) GitHub said the latest repair work includes 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 services. (github.blog) The company also said it moved webhooks off MySQL, redesigned user session cache, reworked authentication and authorization flows to cut database load, and used its Azure migration to add more compute. (github.blog) On the status side, GitHub rolled out a new “Degraded Performance” label on April 17 and began publishing per-service uptime percentages over the last 90 days. (github.blog) As of April 29, GitHub’s status page showed Pull Requests in “Degraded” state with 99.55% uptime over the past 60 days, while Git Operations showed 99.75% and Actions showed 99.69%. (githubstatus.com) GitHub said no pull request data was lost in the latest incident, and pages and interfaces that do not rely on Elasticsearch, including `gh pr list` and the pull request application programming interface endpoint, remained available while reindexing continued. (githubstatus.com) The company’s closing message was narrower than a product launch or roadmap promise: availability first, then capacity, then new features. (github.blog)