---
id: "INC-pypi-77qzc7qsb5wb"
kind: "incident"
aliases: []
title: "PyPI: PyPI Backends are unavailable."
severity: "high"
cvss: null
epss: null
exploited: false
status: "resolved"
category: "vendor"
products: [{"name": "PyPI", "fixed": [], "affected": "", "ecosystem": "vendor"}]
ecosystems: ["vendor"]
tags: ["incident", "pypi", "python", "registry", "security", "vendor"]
not_affected_if: []
published_at: "2022-10-24T14:51:38+00:00"
first_seen_at: "2026-10-23T19:12:22+00:00"
updated_at: "2026-10-25T05:41:44+00:00"
sources: [{"source": "statuspage", "url": "https://stspg.io/p65rhl0q63h1", "first_seen_at": "2026-10-23T19:12:22+00:00"}]
---

# PyPI: PyPI Backends are unavailable.

During cluster maintenance on 2022-10-24, PyPI's HTTPS listener was disabled because the Kubernetes ingress could not find its previous ACM TLS certificate after a hostname change. PyPI uploads and CDN page fetches failed until the ingress was pointed at the new certificate, about twenty minutes later; this is an availability outage with no attacker involved.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:PyPI affected ? fixed ?

## Timeline

- 2026-10-23T19:12:22+00:00 statuspage https://stspg.io/p65rhl0q63h1

## From the sources

## Summary

The cluster that hosts PyPI’s backends as well as multiple ancillary services experienced an outage during maintenance that interrupted access to services over HTTPS.

## Details

From 2022-10-24 14:43 UTC until 2022-10-24 15:03 UTC, PyPI’s backends were not accessible over HTTPS. This interfered with our CDNs ability to fetch pages, made uploads to [uploads.pypi.org](http://uploads.pypi.org) impossible, and interrupted other services such as our legacy file redirect service.  
  
PyPI services run as deployments in a Kubernetes cluster and are exposed via Ingress with the AWS Elastic Load Balancer \(ELB\) integration. The TLS certificate that this load balancer uses is managed via Amazon’s Certificate Manager \(ACM\). When initially deploying our Kubernetes cluster, the Ingress managed ELB was configured to use an existing ACM TLS certificate.  
  
Earlier today, regular maintenance of our Kubernetes cluster required a rolling restart of all nodes in the cluster to distribute upgrades and new configurations to all nodes. During this rolling restart as the Kubernetes API server hosts were deployed, Kubernetes validated and refreshed the Ingress configurations we had previously defined.  
  
Since the most recent rolling upgrade, an additional hostname was needed for PyPI’s Ingress. PyPI administrators created a new ACM TLS certificate including that hostname and updated the Ingress managed ELB to use this new certificate. As a result, the new Kubernetes API servers were unable to find the previous ACM TLS certificate and disabled the HTTPS listener for the Ingress configuration that serves PyPI and associated services as they came online.  
  
Once identified, the PyPI admins updated the Ingress configuration to point to the new ACM TLS certificate and Kubernetes restored the HTTPS listener on the Ingress managed ELB, restoring access to all services.

## Mitigation

We will investigate mechanisms by which the hostnames needed on ACM TLS certificates for PyPI’s Ingress configurations can be managed via Kubernetes resources rather than manually via the AWS console. By managing resources all via the Kubernetes API, drift between desired state and reality will be less likely to occur and surface during similar maintenance in the future.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_