Live

Increased timeouts due to surge in anonymous users

0

GitHub reports 504 Gateway Timeout errors for anonymous and unauthenticated requests. The errors affect users who are not logged in and release downloads. Logged-in users and authenticated requests are unaffected. GitHub resolved the incident after 3 hours and 11 minutes.

State

Resolved

Started

Lasted

3 h 11 min

Worst impact

Degraded

Timeline

9 updates
05:5906:4607:3408:2209:09
DegradedUpdate postedTimes in UTC

Investigating

2 h 16 min 71%

Monitoring

55 min 29%

Updates

Times in UTC

As posted by GitHub

Resolved

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

Monitoring

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

Investigating

Error rates have declined again, and we’re preparing targeted traffic controls while monitoring for a recurrence. Logged-in users and authenticated requests have not been affected.

Investigating

We are continuing to observe high rates of 504 errors for anonymous requests. We are continuing to work on mitigation. Logged-in users and authenticated requests are unaffected.

Investigating

We have observed a repeated increase in 504 errors for anonymous and unauthenticated traffic, including users who are not logged in and release downloads. We are continuing to investigate and apply mitigations.

Monitoring

The problem with anonymous traffic receiving 504 status codes has been mitigated. We are continuing to observe for an abundance of caution.

Monitoring

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

Investigating

We are debugging a spike in anonymous traffic. Some users who are not logged in may see errors on the site. CI jobs and release downloads may fail with a 504 Gateway Timeout status if they make anonymous calls.

Investigating

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

GitHub in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

60

Days with an incident

42

Median duration

1 h 16 min

This incident

2.5× the median

How long each incident lasted, on the day it started. The outlined bar is this incident.

20 h 7 min
median 1 h 16 min
90 days agoToday

Other GitHub incidents

All incidents

Follow GitHub

Your coding agent knows when GitHub is down, and tells you when a failure is theirs, not yours. You can also get GitHub incidents in a feed reader or in Slack.

Prompt
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.

Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.

Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "github" and tell me if GitHub has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.

Paste this into any coding agent. It adds the server with its own MCP setup.

RSS
https://outages.live/feed.xml?providers=github
Slack
/feed subscribe https://outages.live/feed.xml?providers=github

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane