Fly.io Status: How to Check If Fly.io Is Down (2026)
Updated June 2026 · 5 min read · By API Status Check
Quick Answer: Check Fly.io Status Now
Fly.io is a developer-focused platform for running containerized applications close to users across 35+ global regions. Unlike traditional PaaS providers, Fly runs apps as lightweight hardware-virtualized Machines (built on Firecracker microVMs) that can scale to zero, wake on request, and run in any of its worldwide regions. When Fly.io goes down — even partially in a single region — apps deployed there can become unreachable, deployments can stall, and Fly Postgres databases can lose connectivity. This guide explains how to check Fly.io's status and distinguish a platform outage from an app-level issue.
Understanding Fly.io's Status Page (status.flyio.net)
Fly.io operates status.flyio.net — its official status page. Unlike most status pages that show a single global status, Fly.io breaks down its status by individual region (ORD, LAX, AMS, NRT, SYD, etc.) and service component. This is important: a Fly outage in AMS (Amsterdam) doesn't affect your apps in ORD (Chicago).
Fly Machines
The core compute layer — Firecracker microVMs running your containers. Machine incidents affect app availability directly: new requests fail to be routed, stopped Machines cannot start, and health checks fail. Tracked per region.
Networking / Anycast
Fly's global anycast network routes traffic to the nearest region running your app. Networking incidents cause request routing failures even when Machines are healthy — your app is running but traffic can't reach it.
Fly Postgres
Fly-managed Postgres clusters (built on Fly Machines + Patroni). Postgres incidents are tracked separately from compute — a Machines incident in a region may not affect your Postgres cluster if it's in a different region or on separate hardware.
Tigris Object Storage
Fly's globally distributed S3-compatible object storage (powered by Tigris). Storage incidents affect file uploads, static assets, and any app feature that reads/writes objects to Tigris buckets.
Fly API
The API powering `fly` CLI commands, deployments, and the Fly dashboard (fly.io/dashboard). API incidents block deployments and app configuration changes — running apps are usually unaffected during API-only incidents.
Fly Dashboard
fly.io/dashboard — the web console for managing apps, Machines, and billing. Dashboard incidents prevent browser-based management but don't affect running apps or the CLI.
What Fly.io Status Colors Mean
⚠️ Fly.io Platform Issue vs. App Issue — Know the Difference
Many "Fly.io is down" reports are actually app-level issues: a failing health check causing Machines to be deregistered, an app crashing on startup due to a bad deploy, or a Fly Postgres primary failover. Before assuming a platform outage:
- Run
fly status -a <app-name>to check Machine health - Run
fly logs -a <app-name>to check for crash loops - Check health check configuration in
fly.toml - Verify the region you're deploying to is operational on status.flyio.net
Monitor your Fly.io apps with independent uptime monitoring
Fly.io's status page shows platform health by region — not your individual app's uptime. Better Stack monitors your actual Fly app endpoints and alerts you when they go down, before Fly acknowledges an incident. Free plan available.
Try Better Stack Free →5 Ways to Check If Fly.io Is Down
status.flyio.net (Official)
Fly.io's official status page, showing per-region status for Machines, Networking, Fly Postgres, Tigris, and the API. The most reliable source for platform-wide incidents. Check the specific region where your app is deployed.
Check status.flyio.net →fly status CLI Command
Run `fly status -a <app-name>` from your terminal. This shows the real-time state of all your Machines — whether they're running, stopped, or in a failed state. Unlike the status page, this is app-specific and catches issues not reflected in platform-wide status.
Fly CLI docs →community.fly.io
Fly.io's community forum is very active during incidents. Users post reports and workarounds faster than the official status page is updated. Search for the current date + 'down' or 'outage' to find active incident threads.
Check Fly community →@flydotio on X
Fly.io's official X account posts incident updates, postmortems, and maintenance announcements. The Fly team is responsive on X and often acknowledges incidents here before the status page is updated.
Follow @flydotio →X / Twitter (Search)
Search 'fly.io down' or 'flyio outage' on X. The developer community reports Fly outages quickly, especially in the Indie Hackers, Rails, and Elixir/Phoenix communities that use Fly heavily.
Search X for 'fly.io down' →Common Fly.io Issues and What They Mean
"Machine failed to start / Error starting VM"A Fly Machine couldn't start. Common causes: OOM (out of memory — increase [vm] memory in fly.toml), a bad image that fails to run (check `fly logs`), or a region-level incident. Try deploying to a different region with `fly deploy --region <region>`."Health check failed — machine is unhealthy"Your fly.toml health check is failing. The Machine is running but the process inside isn't responding on the configured port/path. Check `fly logs` for startup errors. Common cause: the app isn't binding to the PORT environment variable (Fly sets $PORT, not a fixed port number)."Deployment failed / release command failed"The `release_command` in fly.toml (often a database migration) failed during deployment. Check `fly logs` for the migration error. Fly rolls back the deploy automatically if the release command exits non-zero."fly postgres connect — could not connect to server"Fly Postgres connection failure. Check `fly status -a <postgres-app-name>` to see if the primary is healthy. If the primary is stopped, run `fly machines start <machine-id>`. A Patroni failover may be in progress — wait 30-60 seconds and retry."Error: dial tcp: connect: connection refused"The app process inside the Machine isn't listening on the expected port. Verify your app listens on $PORT (not a hardcoded 3000 or 8080). Check fly.toml [http_service] internal_port matches the port your app uses."wireguard tunnel timeout"Fly uses WireGuard for private networking between Machines. A tunnel timeout usually means the WireGuard peer on Fly's side is unreachable — run `fly wireguard reset` and reconnect. This affects fly SSH, fly proxy, and internal .internal DNS between Machines.Fly.io Outage History: What the Data Shows
Fly.io runs its own hardware in colocation facilities worldwide rather than running on AWS or GCP. This gives Fly more control over its infrastructure but also means incidents sometimes involve physical hardware issues that take longer to resolve. Most incidents are region-specific — a Machines outage in AMS doesn't affect apps in ORD or LAX. If your app availability SLA is critical, deploy to multiple regions with Fly's anycast routing, which automatically routes traffic to healthy regions during an incident.
What to Do When Fly.io Is Down
If Your Fly App Is Unreachable
- Run
fly status -a <app>to check Machines - Check
fly logs -a <app>for crash loops - Verify the region on status.flyio.net
- Try deploying to a secondary region
- Check community.fly.io for active incident threads
If Fly Postgres Is Down
- Run
fly status -a <pg-app> - Check if primary Machine is running
- Run
fly postgres failover -a <pg-app>if primary is stuck - Use
fly postgres connectto test direct connection - Consider read-only fallback to a replica if possible
Frequently Asked Questions
Where is the official Fly.io status page?
Fly.io's official status page is at status.flyio.net. It shows per-region status for Fly Machines, Networking, Fly Postgres, Tigris Object Storage, and the Fly API. You can subscribe to email or Slack notifications to receive updates when incidents are posted and resolved.
My Fly app is down but status.flyio.net shows all green — what should I check?
When the status page shows green but your app is unreachable, the issue is almost always app-level, not platform-level. Run `fly status -a <app>` to check Machine health, `fly logs -a <app>` to check for crashes, and verify your health check in fly.toml. Common causes: the app process isn't binding to $PORT, a health check path is returning a non-200 status, or a release command (database migration) failed.
Does Fly.io have different status by region?
Yes — Fly.io's status page breaks down status by individual region (ORD, LAX, AMS, NRT, SYD, and 30+ others). An incident in one region doesn't affect other regions. Check status.flyio.net and look at the specific region where your app is deployed.
How do I make my Fly app survive a regional outage?
Deploy to multiple regions using `fly scale count 2 --region ORD,AMS` (or similar). Fly's anycast network automatically routes traffic to healthy regions when one region is experiencing issues. Fly Postgres requires a separate HA setup — use `fly postgres create --initial-cluster-size 2` for a primary + replica configuration.
How do I monitor my Fly-hosted app uptime independently?
Add a health check endpoint to your app (e.g., GET /health returns HTTP 200) and monitor it with Better Stack or API Status Check Alert Pro. External monitoring catches outages even when Fly's status page hasn't been updated yet, and verifies your app is responding — not just that Fly's infrastructure is running.
Alert Pro
14-day free trialStop checking — get alerted instantly
Next time Fly.io goes down, you'll know in under 60 seconds — not when your users start complaining.
- Email alerts for Fly.io + 9 more APIs
- $0 due today for trial
- Cancel anytime — $9/mo after trial