GitHub Status · History · Incident #4387
RESOLVEDPull Requests and Issues unavailable for signed-out users
Critical · Started Jun 8, 2026 · 7:11 AM
$HTTP_PROTOCOL = (isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == 1)) || (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') ? 'https://' : 'http://'; $SITE_URL = $HTTP_PROTOCOL . $_SERVER['SERVER_NAME'] . '/'; ?>
GitHub Status · History · Incident #4387
RESOLVEDCritical · Started Jun 8, 2026 · 7:11 AM
Duration
1h 24m
Severity
Critical
Detection lead
—
User reports
—
Summary
On June 8, 2026, between approximately 06:30 UTC and 08:36 UTC, signed-out users experienced sustained elevated HTTP 504 errors when accessing Pull Requests, Issues, releases, patch diffs, and other related GitHub.com pages. During the incident, approximately 17% of unauthenticated requests to the affected GitHub.com endpoints returned gateway timeout errors, peaking at roughly 34% of requests at around 06:50 UTC. Some GitHub Actions workflows were also affected when they depended on release downloads or related GitHub.com endpoints. The impact lasted approximately two hours and was isolated to unauthenticated traffic; signed-in users were not affected. <br /><br />The issue was caused by a significant increase in abusive traffic to specific GitHub.com endpoints. This degraded our ability to respond to unauthenticated requests, causing requests to queue beyond timeout thresholds and return gateway timeout errors. <br /><br />We mitigated the incident by identifying the anomalous traffic pattern and applying targeted blocks at the load balancer and application layers. Error rates returned to normal and affected services were fully restored by 08:36 UTC. <br /><br />To reduce the likelihood and impact of similar incidents in the future, we are improving automated detection and blocking for these traffic patterns, improving our emergency traffic-blocking deployment path, and evaluating routing changes for endpoints used by both signed-out users and automated workflows.
Started
Jun 8, 2026 · 7:11 AM
Resolved
Jun 8, 2026 · 8:36 AM
Duration
1h 24m
Severity
Critical
Event timeline
Investigating
Jun 8 · 7:11 AM GitHubWe are investigating reports of impacted performance for some GitHub services.
Investigating
Jun 8 · 7:14 AM GitHubIssues is experiencing degraded availability. We are continuing to investigate.
Investigating
Jun 8 · 7:31 AM GitHubIssues is experiencing degraded performance. We are continuing to investigate.
Investigating
Jun 8 · 7:32 AM GitHubPull Requests is experiencing degraded performance. We are continuing to investigate.
Investigating
Jun 8 · 8:13 AM GitHubFollowing investigation, we are seeing that impact is limited to unauthenticated users when accessing Pull Requests, Issues, or Actions. Our team continues to work towards mitigation with more updates to follow as we have them.
Investigating
Jun 8 · 8:27 AM GitHubActions is experiencing degraded performance. We are continuing to investigate.
Monitoring
Jun 8 · 8:35 AM GitHubThe degradation affecting Actions, Issues and Pull Requests has been mitigated. We are monitoring to ensure stability.
Resolved
Jun 8 · 8:36 AM GitHubOn June 8, 2026, between approximately 06:30 UTC and 08:36 UTC, signed-out users experienced sustained elevated HTTP 504 errors when accessing Pull Requests, Issues, releases, patch diffs, and other related GitHub.com pages. During the incident, approximately 17% of unauthenticated requests to the affected GitHub.com endpoints returned gateway timeout errors, peaking at roughly 34% of requests at around 06:50 UTC. Some GitHub Actions workflows were also affected when they depended on release downloads or related GitHub.com endpoints. The impact lasted approximately two hours and was isolated to unauthenticated traffic; signed-in users were not affected. <br /><br />The issue was caused by a significant increase in abusive traffic to specific GitHub.com endpoints. This degraded our ability to respond to unauthenticated requests, causing requests to queue beyond timeout thresholds and return gateway timeout errors. <br /><br />We mitigated the incident by identifying the anomalous traffic pattern and applying targeted blocks at the load balancer and application layers. Error rates returned to normal and affected services were fully restored by 08:36 UTC. <br /><br />To reduce the likelihood and impact of similar incidents in the future, we are improving automated detection and blocking for these traffic patterns, improving our emergency traffic-blocking deployment path, and evaluating routing changes for endpoints used by both signed-out users and automated workflows.
Pulsetic catches degradations minutes before vendors acknowledge them.
Stay online, all the time, with Pulsetic's uptime prime.
By Designmodo
Designmodo Inc. 169 Madison Ave, #79627, New York, NY 10016, United States
Copyright © 2010-2026