Cases2 cases
1 to 2 of 2
- 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.
- 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
- Component
- Contributing factor
- 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.
IL-0343DNS names under digitaloceanspaces.com stopped resolving, breaking Spaces, Container Registry and the Control PanelDigitalOcean2024- 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.
- 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
- Component
- Contributing factor
- 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
These 2 cases involve Object storage and CDN and edge network. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause1
Dependency failure2 cases
- Component
- Contributing factor
- Organisation