# Fly.io status

> Is Fly.io down? Live status, uptime history, and per-region response times, measured by our own probes since August 2026.

Published: 2026-08-25 | Canonical: https://yoping.me/status/fly-io

## How we check Fly.io

We watch api.fly.io 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 pin the exact response code the platform API returns to an unauthenticated request rather than assuming any 2xx, since a bare request with no auth token is correctly rejected on a healthy day and a monitor that reads that rejection as downtime would misreport every one of those healthy days.

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/fly-io. 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 Fly.io?

Fly.io runs applications as lightweight virtual machines spread across a
global network of physical locations, built specifically around the idea
that an app should run close to the users making requests to it rather
than in one central region everyone connects to regardless of where they
actually are. A team deploys a container, and Fly.io can run instances of
it in several regions at once, routing each visitor's request to a nearby
one.

That distributed-by-default design changes what an outage typically looks
like compared to a single-region host. A platform-level incident
affecting one region does not necessarily take an application fully
down, if that application is deployed across multiple regions, traffic
can keep flowing through the healthy ones while the affected region
recovers. An application deployed to only a single region, however, gets
none of that protection, and a regional incident there looks exactly like
a full outage from a visitor's perspective.

That makes the practical question after something breaks a genuinely
useful one to ask: is this Fly.io's platform, or is it this specific
application's own deployment choices? A crashed machine, a deploy that
shipped a bug, or an application running out of allocated memory each
produce the same visible symptom, a service that stops responding, as a
real platform-side incident would, and only checking the platform's own
health independently can tell the two apart quickly.

Fly.io's own incidents tend to be scoped to a specific region or a
specific piece of infrastructure, its API, its proxy layer, a particular
data center, rather than the entire global network failing at once,
which is part of why a check running from multiple regions, the way the
board above does, is more informative than a single-location one. If your
own app is down and the board above shows Fly.io healthy, the more
likely explanation is something in your own deploy or machine
configuration rather than the underlying platform.

## Frequently asked questions

### Is Fly.io down right now?

Check the board above; it reflects our own probes against the platform API, refreshed every couple of minutes from all five of our regions.

### My app on Fly.io is unreachable. Is that a platform outage?

Not necessarily. A crashed machine, a bad deploy, or your own app running out of memory produces the same symptom, unreachable, as a genuine platform-side incident. If the board above shows Fly.io healthy, check your own app's logs and machine status before assuming an outage.

### Does an incident in one Fly.io region take down my app everywhere?

Depends on how your app is deployed. Fly.io is built around running an app's machines in multiple regions close to users, and an app deployed across several regions can keep serving traffic from healthy ones while a single region has trouble, an app deployed to only one region does not have that fallback.

### How is this different from Fly.io's own status page?

Theirs reflects incidents their own team has confirmed and posted. Ours reflects what we measure independently from outside their infrastructure, on a fixed schedule regardless of whether an official update has gone up yet.