Where does this status come from?

From PyPI's own status page API at https://status.python.org. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are PyPI's words.

How can my agent or app check PyPI status?

Fetch https://upbutler.com/status/pypi/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"pypi"}, on https://upbutler.com/mcp/public.

How do I know whether an outage is mine or PyPI's?

Add "pypi" to the dependencies of your UpButler workspace. When one of your monitors fails while PyPI has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

Is PyPI down?

Right now

No. PyPI is operational.

No incidents reported.

Read from status.python.org 19 s ago · every 120s

For agents

proceed

Proceed.

GET upbutler.com/status/pypi/status.agent.json

MCP: upstream_status {"service":"pypi"}

The Python Package Index and python.org infrastructure.

What PyPI reports

Operational

Taken as is from PyPI's own status page API. Incident titles and component names below are theirs.

Open status.python.org

UpButler's independent probe

Simple index is answeringHTTP 200 · 27 ms

One request without credentials to pypi.org every two minutes. An answer shows the edge, TLS and routing work. It does not prove that authenticated calls succeed.

Checked 69 s ago · up since 2026-10-10 01:23 UTC

PyPI components

80 operational

python.org

python.org - CDNOperational
python.org - BackendsOperational
python.org - Downloads BackendsOperational

mail.python.org

Message Handling ServicesOperational
Mailing Lists and Archives - MailmanOperational
Mailing Lists and Archives - Mailman 3Operational

docs.python.org

docs.python.org - BackendsOperational
docs.python.org - CDNOperational

PyPI Hosting Platforms

AWS elasticache-us-east-2Operational
AWS elb-us-east-2Operational
AWS ec2-us-east-2Operational
AWS rds-us-east-2Operational
Google Cloud Platform Google Cloud StorageOperational

PyPI

pypi.org - GeneralOperational
pypi.org - CDNOperational
pypi.org - BackendsOperational
pypi.org - EmailOperational
files.pythonhosted.org - FilesOperational
files.pythonhosted.org - RedirectsOperational
files.pythonhosted.org - Redirects BackendsOperational

PyPy

speed.pypy.orgOperational

Content Delivery Network

Fastly Asia/Pacific (HK)Operational
Fastly US East (IAD)Operational
Fastly US East (MIA)Operational
Fastly US Central (DEN)Operational
Fastly US Central (DFW)Operational
Fastly US West (SEA)Operational
Fastly US West (SJC)Operational
Fastly Europe (FRA)Operational
Fastly Europe (AMS)Operational
Fastly Europe (LHR)Operational
Fastly Asia/Pacific (SYD)Operational
Fastly Asia/Pacific (NZ)Operational
Fastly Brisbane (BNE)Operational
Fastly Dubai (FJR)Operational
Fastly Melbourne (MEL)Operational
Fastly Osaka (ITM)Operational
Fastly Perth (PER)Operational
Fastly Tokyo (HND)Operational
Fastly Tokyo (TYO)Operational
Fastly Wellington (WLG)Operational
Fastly Dublin (DUB)Operational
Fastly Copenhagen (CPH)Operational
Fastly Frankfurt (HHN)Operational
Fastly Helsinki (HEL)Operational
Fastly London (LON)Operational
Fastly Madrid (MAD)Operational
Fastly Manchester (MAN)Operational
Fastly Milan (MXP)Operational
Fastly Oslo (OSL)Operational
Fastly Buenos Aires (EZE)Operational
Fastly Bogota (BOG)Operational
Fastly Curitiba (CWB)Operational
Fastly Rio de Janeiro (GIG)Operational
Fastly Santiago (SCL)Operational
Fastly Johannesburg (JNB)Operational
Fastly Cape Town (CPT)Operational
Fastly Vancouver (YVR)Operational
Fastly Toronto (YYZ)Operational
Fastly St. Louis (STL)Operational
Fastly Palo Alto (PAO)Operational
Fastly Newark (EWR)Operational
Fastly New York (LGA)Operational
Fastly Montreal (YUL)Operational
Fastly Minneapolis (STP)Operational
Fastly Minneapolis (MSP)Operational
Fastly Los Angeles (BUR)Operational
Fastly Kansas City (MCI)Operational
Fastly Houston (IAH)Operational
Fastly Dallas (DAL)Operational
Fastly Columbus (CMH)Operational
Fastly Chicago (CHI)Operational
Fastly Boston (BOS)Operational
Fastly Atlanta (PDK)Operational
Fastly Atlanta (FTY)Operational
Fastly Ashburn (WDC)Operational

bugs.python.orgOperational
wiki.python.orgOperational
psfmember.orgOperational
us.pycon.orgOperational

PyPI incidents, last 90 days

3 finished incidents seen since UpButler started tracking on 2026-10-10, 1 of them rated major or critical by PyPI. A typical one lasted 17 min; the longest 12 h 42 min.

Started (UTC)	Incident	Impact	Lasted
2026-10-02 01:15	PyPI Backends Partial Availability	major	17 min
2026-10-01 11:13	Multiple services unavailable	none	6 min
2026-09-28 12:42	Issues with search, logins and logged-in pages	minor	12 h 42 min

Tell your outage from PyPI's

Declare that your project depends on PyPI. When one of your monitors fails while PyPI has an incident that began around the same time, UpButler tags your incident "likely upstream" with their incident linked, says so in the alert and the AI report, and tells your on-call agent not to change code.

npx upbutler init finds the dependency from your env var names and packages. The catalog, dependencies and upstream-aware incidents are on every plan, including Free.

Start free How it works

upbutler.yaml

# upbutler.yaml
dependencies:
  - pypi

Ask before you retry

curl -s https://upbutler.com/status/pypi/status.agent.json

status.agent.json (live)

{
  "schema": "upbutler.upstream-status/v1",
  "service": "pypi",
  "verdict": "proceed",
  "status": "operational",
  "reason": "No incidents reported",
  "retryAfterSec": null,
  "incident": null,
  "probe": {
    "state": "up",
    "statusCode": 200
  }
}

Questions

Is PyPI down right now?: No. As of 2026-10-10 05:14 UTC, PyPI is operational. This page reads the status again every 2 minutes.
Where does this status come from?: From PyPI's own status page API at https://status.python.org. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are PyPI's words.
What does UpButler's own PyPI check prove?: Every two minutes UpButler sends one request without credentials to the PyPI Simple index (pypi.org). Any answer from the edge, usually HTTP 200, shows that DNS, TLS and routing work. It does not prove that authenticated requests succeed, so it can say "reachable" while PyPI reports degraded service. It is useful the other way round: when the probe fails before their status page changes.
How can my agent or app check PyPI status?: Fetch https://upbutler.com/status/pypi/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"pypi"}, on https://upbutler.com/mcp/public.
How do I know whether an outage is mine or PyPI's?: Add "pypi" to the dependencies of your UpButler workspace. When one of your monitors fails while PyPI has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

More in code, packages and workflows

UpButler is not affiliated with PyPI. Status and incident text belong to PyPI and are read from their public status source; the probe result is UpButler's own measurement.