Investigating errors on GitHub

Updates timeline

1. Investigating Apr 23, 02:40 PM UTC

   We are investigating reports of degraded performance for Actions

2. Investigating Apr 23, 02:41 PM UTC

   Packages is experiencing degraded performance. We are continuing to investigate.

3. Investigating Apr 23, 02:42 PM UTC

   Codespaces is experiencing degraded performance. We are continuing to investigate.

4. Investigating Apr 23, 02:44 PM UTC

   Copilot is experiencing degraded performance. We are continuing to investigate.

5. Investigating Apr 23, 02:51 PM UTC

   Users are experiencing errors loading various web pages on github.com. Actions and Copilot Cloud Agent runs will be delayed.

6. Investigating Apr 23, 03:02 PM UTC

   A mitigation was applied and services have recovered.  Actions is working through queued work before fully recovering.

7. Monitoring Apr 23, 03:02 PM UTC

   The degradation affecting Actions, Codespaces, Copilot and Packages has been mitigated. We are monitoring to ensure stability.

8. Resolved Apr 23, 03:18 PM UTC

   On April 23, 2026 between 14:30 UTC and 15:18 UTC multiple services were degraded on github.com. During this time approximately 1.5% of all web requests resulted in a 5xx status and unicorn pages for github.com users. We also saw elevated error rates across Actions workflow runs, Copilot, Codespaces and Packages, leading to degraded experiences during this timeframe. Codespaces impact peaked at 45% failures for create requests and 65% failures for resume requests. Packages impact was mainly Maven related with 50% failure rates in downloads and 70% failure rates in uploads. Actions experienced a peak of 8% of failed jobs and up to 85% of jobs impacted by run start delays of more than 5 minutes.<br /><br />This was due to a configuration change to an internal billing service that led to a cache being overwhelmed and causing requests to time out. These timeouts cascaded across multiple services and eventually caused requests to queue up and exhaust web request workers.<br /><br />This configuration change was reverted at 14:42 UTC and following this, all services began to see recovery immediately.<br /><br />To prevent this situation in the future, we are taking steps to ensure that failures and timeouts in the billing service don’t cascade to other services causing impact. This includes implementing more aggressive timeouts on callers of these billing services, adding circuit breaker configurations for cache timeouts and using more resilient cache options. We have also decreased max request timeouts within the billing service that caused impact and added more capacity to our cache to prevent traffic spikes from having the same impact.