Disruption with some GitHub services

What to do

• Check whether your product depends on GitHub. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 4h 17m it lasted.

  Anything that failed between 2026-04-09 16:20 UTC and 2026-04-09 20:36 UTC may need a replay.

• Subscribe to GitHub's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=github works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from GitHub 7

1. investigatingApr 9, 2026, 4:20 PM UTC

   We are investigating reports of impacted performance for some GitHub services.

   provider

2. investigatingApr 9, 2026, 4:20 PM UTC

   We are experiencing issues where jobs are being delayed to start for copilot coding agent

   provider

3. investigatingApr 9, 2026, 4:57 PM UTC

   We are investigating delays processing Copilot Cloud Agent jobs

   provider

4. investigatingApr 9, 2026, 5:48 PM UTC

   Copilot Cloud Agent jobs are being processed and we are monitoring recovery

   provider

5. investigatingApr 9, 2026, 6:57 PM UTC

   We are continuing to investigate Copilot Cloud Agent job delays

   provider

6. investigatingApr 9, 2026, 7:52 PM UTC

   We continue to investigate periodic delays in Copilot Cloud Agent job processing

   provider

7. resolvedApr 9, 2026, 8:36 PM UTC

   On April 9, 2026, between 16:05 UTC and 20:36 UTC, the Copilot cloud agent service was degraded, causing new agent sessions to be delayed or fail to start. Users who attempted to start Copilot cloud agent sessions during this period experienced jobs getting stuck in the queue, with wait times peaking at 54 minutes compared to the normal 15–40 seconds. On average, approximately 84% of requests to start agent sessions failed, peaking at 97.5% during the worst period. This was due to an internal service exceeding API rate limits, compounded by a caching bug that persisted the rate-limited state beyond the actual rate limit window, causing recurring outage waves rather than a single recovery. We mitigated the incident by deploying a configuration change to bypass the affected cache and shifting API traffic to an alternative authentication path that reduced rate limit exposure. We have since added automated monitoring and alerting for this failure mode, deployed per-endpoint rate limit controls, and added caching for high-traffic API calls to reduce overall load. We are also working on longer-term improvements to rate limit isolation and traffic management to prevent similar issues in the future. This incident shared the same underlying root causes with an incident declared in the time frame https://www.githubstatus.com/incidents/zn1t56bfxdzg

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.