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 1h 21m it lasted.

  Anything that failed between 2026-07-20 00:25 UTC and 2026-07-20 01:46 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 6

1. investigatingJul 20, 2026, 12:25 AM UTC

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

   provider

2. monitoringJul 20, 2026, 12:25 AM UTC

   Some Git LFS operations, and loading files through the API are failing. We are investigating.

   provider

3. monitoringJul 20, 2026, 12:26 AM UTC

   Some Git LFS operations, and loading files through the API are failing. We are investigating.

   provider

4. investigatingJul 20, 2026, 1:15 AM UTC

   The Git LFS API issues have been identified as being related to a separate incident where Actions is experiencing degraded availability. We’re consolidating our investigation efforts under that incident.

   provider

5. investigatingJul 20, 2026, 1:45 AM UTC

   Git LFS API success rates have returned to normal. We will continue to monitor the service closely.

   provider

6. resolvedJul 20, 2026, 1:46 AM UTC

   Between July 19, 2026, at 23:05 UTC and July 20, 2026, at 03:55 UTC, Actions self-hosted and larger runners were unable to connect to GitHub. During this period, Actions jobs were delayed or failed when trying to acquire a runner. Jobs using standard and Mac hosted runners were not affected. Reconnection traffic from affected runners also increased load on GitHub APIs, resulting in 3-4 seconds of additional average request latency and elevated 5xx error rates. The incident was caused by a certificate lifecycle management failure in a subset of internal services, resulting in an SSL certificate expiration that disrupted runner connectivity. We restored service by rotating the affected certificate. Recovery began at 02:45 UTC. By 03:55 UTC, queued workflow backlog had been processed and workflow delay rates returned to normal. To prevent recurrence, we are strengthening certificate renewal automation, adding fallback expiry monitoring and alerting, and improving circuit-breaker protections during runner API disruptions to reduce the risk of cascading impact to other APIs.

   provider

Corrections

None so far.

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