Incident Library
Applied filters OrganisationPython Software FoundationClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases3 cases

1 to 3 of 3

  1. 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.

  2. Symptoms

    From 14:43 to 15:03 UTC on 24 October 2022, during regular maintenance of the Kubernetes cluster that hosts PyPI, PyPI's backends could not be reached over HTTPS. The CDN could not fetch pages, uploads to uploads.pypi.org were impossible, and other services such as the legacy file redirect service were interrupted.

    Trigger

    Regular maintenance did a rolling restart of every node in the cluster to roll out upgrades and new configuration; as the new Kubernetes API server hosts came up, Kubernetes validated and refreshed the Ingress configurations.

    Root cause
    Component
    Contributing factor
    Remediation
    • Pointed the Ingress configuration at the new ACM TLS certificate, and Kubernetes restored the HTTPS listener on the ELB
    Action items
    • Investigate managing the hostnames on the ACM TLS certificates for PyPI's Ingress through Kubernetes resources instead of the AWS console
    Lessons

    When every resource is managed through the Kubernetes API, drift between the desired state and reality is less likely to build up and then surface during later maintenance.

  3. Symptoms

    At 18:23 UTC on 28 July 2022, PSF Infrastructure got an alert that at least one Vault container in PyPI's Kubernetes cluster was down and needed unsealing. At 18:46 UTC PyPI's backends became unresponsive, and they stayed down until 18:53 UTC.

    Trigger

    From 17:24 UTC the cloud provider automatically replaced several instances of PyPI's Kubernetes cluster because of an unknown failure. All replacements were healthy by 18:20 UTC, but the event reshuffled many pods and restarted Consul and Vault on new nodes.

    Root cause
    Component
    Contributing factor
    Detection

    An alert at 18:23 UTC told PSF Infrastructure that at least one Vault container was down and needed unsealing.

    Remediation
    • Forcefully removed the Consul pod stuck in Terminating so it was recreated and Consul could elect a leader
    • Unsealed the new Vault containers
Check your cluster for this

These 3 cases involve CDN and edge network and Cloud load balancer. 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 cause3