Is Fly.io Down? How to Check Fly.io Status Right Now

Fly.io is the deployment platform that runs your Docker containers as Firecracker microVMs across a global anycast network. When it works, deploys are fast, latency is low, and your app scales to the nearest region automatically. When Fly.io has an incident, the failure modes are unusual: your containers may be running but unreachable, your Machines API calls may be hanging silently, your Fly Postgres may be accepting writes that never commit, or your DNS may resolve but your proxy routes traffic to a dead machine. The error signals are subtle and often look like application bugs rather than platform incidents.

Here's how to tell if Fly.io is down, which component is most likely the culprit, and how to keep your team informed before your users notice.

Is Fly.io Down Right Now?

Check these sources in order:

1. Statusfield — Fly.io status — real-time monitoring covering Fly Machines, Fly Proxy, Fly Postgres, DNS, and the Fly API.
2. Fly.io Community — the Fly.io community forum and Discord (community.fly.io) surface platform incidents fast. Developers post when deploys hang or regions fall over.
3. Twitter/X — search fly.io down or flyctl deploy failing sorted by Latest. Backend engineers and DevOps teams surface incidents within minutes.

What Actually Breaks During a Fly.io Outage

Fly.io is not a single system. Machines, the proxy layer, Postgres, DNS, and the API are separate services that can fail independently. A full global outage is rare; regional degradations and single-component failures are common.

Component	What it does	Impact when down
Fly Machines API	Creates, starts, stops, and manages Firecracker microVMs	flyctl deploy hangs or returns 500; new machines cannot be started; scaling is broken
Fly Proxy	Routes incoming traffic to healthy machine instances	Requests return 502/503; your DNS resolves but traffic never reaches your container
Fly Postgres	Managed Postgres clusters running on Fly Machines	DB connections refused; writes may succeed but primary may be unreachable; leader election may be in progress
Fly DNS / Anycast routing	Resolves <app>.fly.dev and routes to the nearest region	Requests cannot reach your app at all; DNS resolution fails or resolves to unreachable IPs
Fly Build (remote builders)	Compiles your Docker image on Fly's remote builder fleet	flyctl deploy --remote-only hangs; image build step times out
Fly API (api.fly.io)	Handles flyctl CLI commands, GraphQL API, and the Fly dashboard	CLI commands return errors; Fly dashboard shows stale state; fly apps list fails
Fly Volumes	Persistent storage mounted into Machines	Volume mounts fail on start; apps with persistent state cannot start
Certificate / TLS provisioning	Issues and renews TLS certs for custom domains	Custom domain requests fail with certificate errors; fly certs commands return errors

Fly.io Error Symptoms and What They Mean

What you see	What it usually means
flyctl deploy hangs indefinitely at "Monitoring deployment"	Machines API is degraded; new machines are being scheduled but not starting
502 Bad Gateway on your *.fly.dev URL	Fly Proxy cannot route to a healthy machine instance — either machines are down or the proxy layer is degraded
Error: failed to get instance: context deadline exceeded	Machines API timeout; the platform is not responding to machine management calls
Fly Postgres connection refused	Postgres primary is unreachable or a leader election is in progress — this is the most common Fly Postgres incident symptom
app.fly.dev DNS resolves but requests time out	Fly Proxy is routing to machines that are not accepting connections, or the anycast routing layer is degraded
fly logs shows no output despite traffic	Log shipping pipeline is degraded; machines may be healthy but logs are not flowing to the aggregator
fly status shows machines as started but app returns 503	Health checks are passing internally but the proxy layer is not routing traffic correctly
Certificate errors on a custom domain after it was working	Fly's TLS termination layer is degraded, or certificate renewal failed
error connecting to parent agent in fly agent logs	Fly's WireGuard-based private network is degraded; inter-machine communication within the same org is broken

How Fly.io's Architecture Affects Outage Scope

Fly.io uses Firecracker microVMs behind an anycast proxy layer, with each region running independently. This gives Fly.io good fault isolation between regions but creates specific failure patterns worth understanding.

Regions are largely independent. If an incident is scoped to a single region (iad, lhr, nrt, etc.), traffic in other regions continues normally. Your app may degrade in one geography while staying fully operational in others. The first signal of a regional incident is often elevated error rates from users in a specific location.

The Fly Proxy is shared infrastructure. Unlike the Machines themselves, the Fly Proxy layer that handles incoming traffic is shared across apps in a region. A proxy-layer incident affects all apps in that region simultaneously, regardless of whether your machines are healthy.

Fly Postgres is not AWS RDS. Fly Postgres is Postgres running on Fly Machines with Patroni for high availability. During a primary failover, there is a period where writes are refused while a new primary is elected. This is expected behavior but looks identical to an infrastructure outage from your application's perspective. The key distinction: a Patroni failover is self-healing within 30–60 seconds, while an infrastructure outage requires Fly intervention.

Deploys touch the Machines API. Every flyctl deploy creates new machines, waits for health checks to pass, and then stops old machines. If the Machines API is degraded mid-deploy, you may be left in a state where old machines are stopped but new machines are not fully started — an accidental partial deploy. This is the most dangerous Fly.io failure mode: it can take your app offline with no automatic recovery.

WireGuard private networking has its own failure mode. Fly's private networking (.internal DNS and WireGuard tunnels) is how machines communicate within an org. A WireGuard plane incident breaks inter-service calls on the private network while the public proxy may stay healthy — so your app receives public traffic but cannot reach its own Postgres or Redis sidecar.

Local Issues That Look Like Fly.io Outages

Before concluding Fly.io is down, rule out these common misdiagnoses:

Your machine failed a health check and was replaced. Fly.io stops machines that fail health checks and starts new ones. If your CMD or HEALTHCHECK is misconfigured, machines cycle continuously, and deploys never succeed — but the platform is working correctly.

Your app is running out of memory. Fly's default memory allocation is 256 MB. An app that OOMs is killed and restarted by the platform. This creates a pattern of brief successful startups followed by crashes that looks like intermittent platform instability.

Your fly.toml has a stale internal port. [[services.ports]] and [http_service.internal_port] must match the port your process actually binds. A mismatch means the proxy routes traffic to the right machine but no process is listening — 502s result.

Fly Postgres is on a burstable instance that hit CPU credit limits. Fly Postgres clusters on shared CPU instances accumulate and spend CPU credits. A burst of write load can exhaust credits and leave the Postgres instance throttled — not down, but extremely slow.

Your app region has no running machines. If all machines in your primary region have been stopped (by a deploy failure, a scale-to-zero, or a fly scale count 0 accident), new requests still reach the Fly Proxy but there are no machines to route to — 503 results.

When these are ruled out and your app is still unreachable, check Statusfield to confirm whether the platform is degraded.

Hardening Your Fly.io Deployment Against Outages

1. Deploy to at least two regions

A single-region deployment means a regional incident takes your app fully offline. Adding a second region with fly scale count 1 --region lhr (or any region outside your primary) means traffic can be served from the second region during a regional degradation. Fly's anycast routing will automatically direct users to the nearest healthy region.

2. Use a rolling deploy strategy

In fly.toml, configure [deploy] strategy = "rolling" rather than the default canary. Rolling deploys keep old machines running until new ones pass health checks, reducing the window where you have zero healthy machines. The default canary strategy with a single machine instance can leave you with no machines running if the new machine fails its health check.

3. Set explicit health check timeouts

Configure [checks] in your fly.toml with realistic timeout values for your app's startup time. Under-configured health checks (default 2s timeout) cause machines to fail health checks during normal cold starts, triggering unnecessary machine cycles that look like platform instability.

4. Store credentials in Fly Secrets, not in your image

fly secrets set KEY=value stores secrets in Fly's encrypted secret store, injected as environment variables at machine start. Secrets stored in the Docker image are visible in the image layers and are not rotated on secret rotation. Fly Secrets are the only safe way to handle credentials on the platform.

5. Monitor Fly.io as a dependency, not as background noise

A Fly.io incident at 2 AM during a deploy is the worst time to discover you don't have visibility into platform status. Statusfield monitors Fly.io's Machines, Proxy, Postgres, and API continuously. When degradation is detected, you get an alert through Slack, Discord, email, or webhook before your users are affected.

How to Stay Ahead of Fly.io Outages

Fly.io is your infrastructure, not a peripheral tool. When it goes down, your entire app goes down — and if you discover it from user complaints, you're already behind. The goal is to know about a degradation before your first user reports a problem.

Statusfield monitors Fly.io continuously and alerts your team the moment a component degrades. On the free plan you get 3 monitors — enough to cover Fly.io plus two other critical dependencies — with no credit card required. The Pro plan ($29/mo) covers up to 20 services with unlimited alerts, so your full stack is covered.

→ Monitor Fly.io on Statusfield — free, no credit card required

FAQ

Why is flyctl deploy hanging at "Monitoring deployment"?

This almost always means the Machines API is degraded or your new machines are failing health checks. First, check Statusfield to rule out a platform incident. If Fly.io is operational, review your health check configuration in fly.toml — a timeout that's too short for your app's startup time causes machines to fail health checks repeatedly, leaving the deploy in a monitoring loop. Check fly logs for your app's actual startup output to diagnose.

Is Fly.io down for everyone or just in my region?

Fly.io incidents are often regional. Check Statusfield to see which regions are affected. If you're deployed to a single region, a regional incident takes your app offline entirely. If you're deployed to multiple regions, only users in the affected region see degradation. fly status will show which machines are in which regions and their current state.

My Fly Postgres connection is refused. Is Fly.io down?

Not necessarily. The most common cause is a Patroni leader election in progress — this takes 30–60 seconds and self-heals. Check Statusfield first to rule out a platform-level Postgres incident. If the status shows operational, wait 60 seconds and retry. If connections are still refused after 2 minutes, run fly postgres status -a <postgres-app-name> to check primary election state. A prolonged leader election may indicate an underlying machine failure.

My app returns 502. The machines show as "started" in fly status. What's wrong?

A 502 with started machines usually means the Fly Proxy cannot reach your machine on the configured internal port. Verify the internal_port in your fly.toml matches the port your process binds. Also confirm your process is binding to 0.0.0.0 (not 127.0.0.1) — Fly's proxy routes to the machine's network interface, not localhost. If the port is correct and the process is binding correctly, check Statusfield for a proxy-layer incident.

How do I recover from a failed Fly.io deploy that left no machines running?

If a deploy failure left you with zero healthy machines, your fastest recovery path is to deploy a previous known-good image. Run fly releases to list your release history, then fly deploy --image <image-ref> to deploy a specific image. If you don't have a rollback image, rebuild from your last working commit. Avoid running fly scale count 0 or fly machines destroy during a recovery — those remove your infrastructure rather than recovering it.