Where does this status come from?

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

How can my agent or app check RunPod status?

Fetch https://upbutler.com/status/runpod/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":"runpod"}, on https://upbutler.com/mcp/public.

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

Add "runpod" to the dependencies of your UpButler workspace. When one of your monitors fails while RunPod 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 RunPod down?

Right now

No. RunPod is operational.

No incidents reported.

Read from uptime.runpod.io 12 s ago · every 300s

For agents

proceed

Proceed.

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

MCP: upstream_status {"service":"runpod"}

GPU pods and serverless endpoints.

What RunPod reports

Operational

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

Open uptime.runpod.io

UpButler's independent probe

There is no keyless endpoint of RunPod that says anything useful, so UpButler does not probe it. To check your own RunPod account, add a monitor with your key: it is yours alone and catches what a shared probe cannot.

RunPod components

42 operational

Serverless

serverless api: api.runpod.aiOperational
serverless: queue engineOperational
Serverless: CPU workersOperational

GPU Cloud

graphql: api.runpod.ioOperational
log/metrics api: hapi.runpod.netOperational
pod proxy: proxy.runpod.netOperational
graphql: transactional data storeOperational
ui: runpod.io/consoleOperational
Upstream SystemsOperational
CPU CloudOperational

Regional Health

AP-IN-1Operational
AP-JP-1Operational
CA-MTL-1Operational
CA-MTL-3Operational
CA-MTL-4No data
EU-CZ-1No data
EU-FR-1Operational
EU-NL-1Operational
EU-RO-1Operational
EU-SE-1No data
EUR-IS-1Operational
EUR-IS-2Operational
EUR-IS-3Operational
EUR-IS-4Operational
EUR-NO-1Operational
EUR-NO-2Operational
OC-AU-1Operational
US-CA-2Operational
US-GA-2Operational
US-IL-1No data
US-KS-2Operational
US-MD-1Operational
US-MO-1Operational
US-MO-2Operational
US-NC-1Operational
US-NC-2Operational
US-NE-1Operational
US-TX-1No data
US-TX-3No data
US-TX-4Operational
US-WA-1Operational
US-PA-1Operational

RunPod incidents, last 90 days

3 finished incidents seen since UpButler started tracking on 2026-10-10. A typical one lasted 1 h 31 min; the longest 3 h 30 min.

Started (UTC)	Incident	Impact	Lasted
2026-10-09 16:31	US-CA-2 Network Storage Issue	minor	1 h 31 min
2026-10-07 20:30	US-CA-2 Networking is Degraded	minor	31 min
2026-09-29 17:00	EUR-NO-2 Network Storage Issue	minor	3 h 30 min

Tell your outage from RunPod's

Declare that your project depends on RunPod. When one of your monitors fails while RunPod 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:
  - runpod

Ask before you retry

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

status.agent.json (live)

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

Questions

Is RunPod down right now?: No. As of 2026-10-10 05:12 UTC, RunPod is operational. This page reads the status again every 5 minutes.
Where does this status come from?: From RunPod's own status page API at https://uptime.runpod.io. UpButler reads it once for everyone (not once per visitor) every 300 seconds with conditional requests, and shows it unchanged: incident titles and component names are RunPod's words.
How can my agent or app check RunPod status?: Fetch https://upbutler.com/status/runpod/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":"runpod"}, on https://upbutler.com/mcp/public.
How do I know whether an outage is mine or RunPod's?: Add "runpod" to the dependencies of your UpButler workspace. When one of your monitors fails while RunPod 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 hosting and compute

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