Cases3 cases

1 to 3 of 3

1. IL-0515 Downloads from files.pythonhosted.org failed with intermittent 502 and 503 errors for two weeks, breaking PyPI installs

   Python Software Foundation2026

   Symptoms

   For about two weeks in August 2026, some PyPI users got intermittent 502 and 503 errors when downloading files from files.pythonhosted.org, and installations from PyPI failed. The first two reports of persistent 502s were opened in the support tracker on 17 August.

   High error rate

   Trigger

   A partial rollback during a canary deployment inside Fastly's network, whose canary cohort had included PyPI's traffic for a number of years, left the caching configuration of one Seattle point of presence reverted while the routing configuration in front of it was not.

   Root cause

   Dependency failure

   Component

   CDN and edge networkObject storage

   Contributing factor

   Partial rolloutOverlapping failuresSignal buried in noise

   Detection

   Users filed reports in the PyPI support tracker; one report isolated the 502s to a single Fastly cache node using the x-served-by headers of the failing responses.

   Remediation

   • Fastly's network operations removed the routing override that sent part of PyPI's traffic to the affected point of presence
   • Fixed the B2-to-S3 fallback for the case where B2 does not respond at all (infra#237)
   • Exempted suffix and multi-range requests from segmented caching (infra#241, infra#243)
   • Fastly patched the canary configuration bug and removed all PSF traffic from its canary cohort
   • Moved the segmented-caching exemption check after URL normalization (infra#245)

   Action items

   • Improve the logging configuration of the file hosting service (infra#238)
   • Reject HTTP methods that a file host should not receive (infra#239)
   • Follow a support ticket with Fastly about segmented-caching range handling, and revert PyPI's own handling code once Fastly fixes it
   • Return to Fastly's canary program once clearer controls and notifications exist around that traffic
   • Hire an infrastructure engineer, partly for PyPI, to catch conditions like this earlier

   Lessons

   None of the PyPI configuration bugs were new; they had been in the configuration for a while and came out only when real traffic on large files with range requests forced an investigation. The 5xx baseline was already noisy, so the start of the Fastly problem was easy to miss, and part of that noise turned out to be one of the bugs.

   View case
2. IL-0408 OpenRouter's API returned 500s and false 401 "User not found" errors when its API key cache dropped and came back empty

   OpenRouter2026

   Symptoms

   At 5:27 AM UTC on 17 February 2026 part of OpenRouter's users started getting 500 errors on all API endpoints, and from 5:40 AM many requests failed with 401 "User not found" errors although their API keys were valid. The chatroom was degraded at the same time. The same pattern came back at 7:36 AM UTC on 19 February.

   High error rateService outageDatabase overload

   Trigger

   The third-party caching layer in front of API key lookups dropped all of its connections to OpenRouter's database and began returning errors.

   Root cause

   Dependency failure

   Component

   In-memory cacheDatabase

   Contributing factor

   Dependence on a warm cacheOverlapping failures

   Detection

   An internal alert fired one minute after impact began on 17 February, at 5:28 AM UTC, and two minutes after it began on 19 February, at 7:38 AM UTC, and the response team came online to investigate.

   Remediation

   • Deployed WAF rules to block the denial-of-service attack running at the same time on 17 February

   Action items

   • Add circuit breakers that detect caching layer failures, limit their blast radius and repopulate a cold cache in a controlled way
   • Return 503 instead of 401 when an authorization lookup cannot complete because of an infrastructure problem
   • The caching provider fixes the failure mode that caused both incidents
   • Roll out a fallback caching mechanism so OpenRouter survives even extended downtime of the caching layer

   Lessons

   Answering an infrastructure failure with an authentication error made customers debug API keys that were fine, so error codes have to say what actually failed. Attributing the first outage to a concurrent denial-of-service attack, because the caching dependency had always been reliable, left the real fault in place until it recurred two days later. OpenRouter holds that redundancy against failures in its dependencies is its own responsibility, not the provider's.

   View case
3. IL-0343 DNS names under digitaloceanspaces.com stopped resolving, breaking Spaces, Container Registry and the Control Panel

   DigitalOcean2024

   Symptoms

   From 22:38 UTC on 28 November 2024, DigitalOcean's Cloud Control Panel stopped loading for customers, and sign-up and log-in failed. DigitalOcean declared the incident from monitoring and customer reports, an internal alert fired at 22:44 UTC, and Spaces buckets and the services that depend on them began to fail intermittently.

   DNS resolution failuresHigh error rateImage pull failures

   Trigger

   At 22:38 UTC on 28 November 2024, DigitalOcean's domain registrar, Network Solutions, made an update to the digitaloceanspaces.com domain that added an Extensible Provisioning Protocol (EPP) clientHold status code to it.

   Root cause

   Dependency failure

   Component

   Domain registrar and registryObject storageContainer registry and its credentials

   Contributing factor

   Cache-masked failureMonitoring blind spot

   Detection

   DigitalOcean declared the incident at 22:38 UTC based on monitoring and customer reports that the Cloud Control Panel would not load. An internal alert detected the issue at 22:44 UTC, and the first customer contact about the Control Panel came at 22:57 UTC.

   Remediation

   • Deployed a change that brought the Cloud Control Panel back online
   • Contacted Network Solutions to have the clientHold removed
   • Escalated to Verisign executives, the .com registry, until the clientHold was removed

   Action items

   • Work with Network Solutions to understand why the clientHold was applied to the domain
   • Review other domain registrars as possible new homes for DigitalOcean's domains
   • Review monitoring and alerting to detect registrar-imposed changes and DNS resolution problems sooner

   View case

By root cause1