Incident with Pull Requests

What to do

• Check whether you use GitHub Pull Requests. 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 1h 9m it lasted.

  Anything that failed between 2026-09-20 22:13 UTC and 2026-09-20 23:22 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 4

1. investigatingSep 20, 2026, 10:13 PM UTC

   We are investigating reports of degraded performance for Pull Requests

   provider

2. monitoringSep 20, 2026, 10:27 PM UTC

   The degradation affecting Pull Requests has been mitigated. We are monitoring to ensure stability.

   provider

3. monitoringSep 20, 2026, 10:32 PM UTC

   A git fileserver issue caused a brief delay in creating some merge commits - we've isolated the underlying server and already observed recovery.

   provider

4. resolvedSep 20, 2026, 11:22 PM UTC

   On September 20, 2026, between 21:46 and 22:24 UTC the Pull Requests service was degraded and pull request merge and test-merge commits were created late, with delays reaching approximately four minutes at peak. Merge commits were delayed rather than lost. Because some Actions workflow runs start only after a pull request's merge commit is created, a subset of workflow runs for pull request events were also delayed. This was due to a routine repository maintenance job for an unusually large repository consuming nearly all of the memory on a single Git storage server, which left that server unable to serve the Git operations used to create merge commits. We mitigated the incident by removing the affected server from service at 22:18 UTC, after which the queued merge commits were created within six minutes. We have capped the memory a single repository maintenance job may consume so that one repository cannot exhaust a server, and we have improved monitoring and alerting on storage server health to reduce our time to detection and mitigation of issues like this one in the future.

   provider

Corrections

None so far.

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