Fly.io status

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.

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.