PyPI status

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.

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.