Where does this status come from?

From Fly.io's own status page API at https://status.flyio.net. 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 Fly.io's words.

How can my agent or app check Fly.io status?

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

How do I know whether an outage is mine or Fly.io's?

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

Right now

No. Fly.io is operational.

No incidents reported.

Read from status.flyio.net 3 min ago · every 120s

For agents

proceed

Proceed.

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

MCP: upstream_status {"service":"fly"}

Machines, networking and managed Postgres across regions.

What Fly.io reports

Operational

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

Open status.flyio.net

UpButler's independent probe

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

Fly.io components

25 operational

Customer ApplicationsOperational
DashboardOperational
Machines APIOperational
AMS - Amsterdam, NetherlandsOperational
ARN - Stockholm, SwedenOperational
BOM - Mumbai, IndiaOperational
CDG - Paris, FranceOperational
DFW - Dallas, Texas (US)Operational
EWR - Secaucus, NJ (US)Operational
FRA - Frankfurt, GermanyOperational
GRU - Sao Paulo, BrazilOperational
IAD - Ashburn, Virginia (US)Operational
JNB - Johannesburg, South AfricaOperational
LAX - Los Angeles, California (US)Operational
LHR - London, United KingdomOperational
NRT - Tokyo, JapanOperational
ORD - Chicago, Illinois (US)Operational
SIN - SingaporeOperational
SJC - San Jose, California (US)Operational
SYD - Sydney, AustraliaOperational
YYZ - Toronto, CanadaOperational
Persistent Storage (Volumes)Operational
DeploymentsOperational
Remote BuildsOperational
LogsOperational

Fly.io incidents, last 90 days

7 finished incidents seen since UpButler started tracking on 2026-10-10, 4 of them rated major or critical by Fly.io. A typical one lasted 20 min; the longest 1 h 38 min.

Started (UTC)	Incident	Impact	Lasted
2026-10-08 21:23	Sprite creates failing	critical	31 min
2026-10-08 05:40	LHR network issues	major	20 min
2026-10-06 11:59	Impaired IPv6 connectivity in ORD	minor	3 min
2026-10-03 08:01	Partial outage in AMS	critical	57 min
2026-10-01 01:11	Delayed ingestion of app logs	minor	1 h 38 min
2026-09-29 21:12	GRU Networking Issues	none	under a minute
2026-09-26 20:10	Network outage in AMS region	critical	under a minute

Tell your outage from Fly.io's

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

Ask before you retry

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

status.agent.json (live)

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

Questions

Is Fly.io down right now?: No. As of 2026-10-10 05:08 UTC, Fly.io is operational. This page reads the status again every 2 minutes.
Where does this status come from?: From Fly.io's own status page API at https://status.flyio.net. 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 Fly.io's words.
How can my agent or app check Fly.io status?: Fetch https://upbutler.com/status/fly/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":"fly"}, on https://upbutler.com/mcp/public.
How do I know whether an outage is mine or Fly.io's?: Add "fly" to the dependencies of your UpButler workspace. When one of your monitors fails while Fly.io 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 Fly.io. Status and incident text belong to Fly.io and are read from their public status source; the probe result is UpButler's own measurement.