# PyPI status

> Is PyPI down? Live status for the Python Package Index, uptime history, and per-region response times from our own probes every 2 minutes.

Published: 2026-08-23 | Canonical: https://yoping.me/status/pypi

## How we check PyPI

We watch pypi.org from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the index host that pip resolves against, which is the path that decides whether an install succeeds. Package files themselves are served from a separate content network, so a page that only checked downloads would miss the resolution failures that stop a build before a single file is fetched.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/pypi. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## What is PyPI?

PyPI is the package index for Python, and its position in the ecosystem
is close to unavoidable. Installing almost any Python library means
resolving it there, and a moderately sized application will pull dozens
of packages, each with dependencies of its own. Scientific computing,
web development, data pipelines, and machine learning all rest on it,
which puts a volunteer-supported service underneath a very large amount
of commercial software.

The failure mode is narrower than people fear. An outage does not take
production down. Packages already installed in a virtual environment or
baked into a container image keep working; nothing at runtime contacts
the index to confirm they are still published. What stops is the ability
to build. CI fails at the install step, container builds fail on the same
line, a developer setting up the project cannot proceed, and any deploy
that installs dependencies stalls partway through. The application is
fine and the pipeline that changes it is not.

There is a structural detail worth knowing when diagnosing a failure. The
index that resolves package names and versions is not the same system
that serves the package files themselves, which come from a separate
content network. It is possible for resolution to work while downloads
are slow, or for a download to fail while the index answers instantly.
This is why the error message matters more than any status page: a
timeout resolving a name and a timeout fetching a wheel point at
different parts of the system.

The most common false alarm is not an outage at all. Installations fail
regularly because no compatible wheel exists for a given Python version
or platform, which produces an error about no matching distribution and
sends people to check whether PyPI is down. It is not; the package simply
does not exist in the form being requested, often after a Python upgrade
or on an architecture the maintainer does not build for. Corporate
proxies produce the second most common false alarm, since intercepting
TLS makes certificate verification fail in a way that looks like a
network problem.

The broader point is that a package registry is a dependency that almost
nobody plans around. Most teams have no mirror, no cached fallback, and
no documented answer for what to do when the index is unavailable,
because it is reliable enough that the question never arises. Pinning
versions and caching aggressively covers most of the risk for very little
effort, and knowing quickly that the index is the problem covers the
rest.

## Frequently asked questions

### Is PyPI down right now?

Check the board above; it reflects our own probes against pypi.org from all five of our regions, refreshed every couple of minutes. That is the host pip talks to when resolving packages, so it is the reading that matters for a failing install.

### My pip install is failing. Is it PyPI or my setup?

Read the error before assuming an outage. A connection timeout or a reset against pypi.org or files.pythonhosted.org points at the network path or the index; a message about no matching distribution points at a package name, a version, or a Python version that has no compatible wheel; and an SSL error usually points at a corporate proxy intercepting traffic. Only the first is something a status page can help with.

### Does a PyPI outage break my running application?

No. Installed packages live in your environment or your container image and keep working regardless of whether the index is reachable. What stops is installing anything new, which means CI pipelines, container builds, fresh environments, and any deploy that runs an install step. Production keeps running, shipping does not.

### Why does my build fail in CI but work on my machine?

Because your machine usually installs from a warm cache or an environment that already exists, while CI builds resolve from scratch every time. During a partial outage that difference decides who notices, which makes the failure look CI-specific when it is not. A corporate proxy or an internal mirror that CI routes through and your laptop does not produces the same asymmetry.

### Should I run a mirror or pin my dependencies?

Pinning is the higher-value habit and costs almost nothing. A lockfile or a fully pinned requirements file means builds resolve to exact versions rather than searching the index for a satisfying range, which is both more reproducible and less sensitive to a degraded index. A local mirror or proxy goes further and makes sense for teams whose deploys cannot wait, at the cost of infrastructure you then have to run.