Is the PyPI API slow?

One PyPI surface: the JSON metadata document for the pip project, about 230 KB that pypi.org serves through Fastly's cache with a 15-minute lifetime. Tools such as pip, Poetry and dependency scanners read this kind of document to learn which versions exist; it is the lookup step of a Python install. It does not stand for the download step: wheels and source archives come from files.pythonhosted.org, a separate host we measure as its own surface, and the simple index that pip reads by default is a different document again. From outside we cannot see whether the cache answered or the request went through to PyPI's origin; with a 15-minute cache lifetime, a slow request may simply be the first one after expiry.

Between 27 September and 10 October 2026 Tokyo, Mumbai, Amsterdam, Montreal and Singapore had a typical time of 11 to 14 ms, and San Francisco 68 ms. San Francisco's daily median stayed between 56 and 81 ms on all 13 runs, so the gap is steady rather than one bad day. Montreal's typical hides a split: 10 to 13 ms on seven days and 57 to 122 ms on the other six (28 September and 2, 3, 4, 5 and 10 October), which the pooled typical absorbs and the history chart shows. Those days give Montreal a slower time of 122 ms, against 13 to 20 ms in Amsterdam, Singapore, Tokyo and Mumbai and 94 ms in San Francisco. Mumbai was the steadiest city, at 11 or 12 ms on every run. Compare npm, whose registry root is a two-byte cached document, and crates.io, whose metadata is not cached at all.