Fly.io's incident pattern through September and October 2026, verified against their own status page

Fly.io doesn’t have a single headline-grabbing outage to point to for this period — nothing like a multi-day platform collapse. What it has, visible on its own public status page, is a steady cadence: 25 separate incidents between September 2 and October 22, 2026, spanning specific regions, specific services, and a range of severities from “none” to “critical.” That pattern, not any one event, is the actual story, and it’s worth looking at directly rather than through someone else’s summary.

What Fly.io’s own status history shows

Everything below comes from Fly.io’s own incident history at status.flyio.net, read through its public incident API, with Fly’s own timestamps and impact classifications.

Upstash unavailability in FRA region — September 23, major. From roughly 12:00 to 13:05 UTC, clients got connection timeouts to Redis databases hosted in the fra or gig regions, and to databases elsewhere whose connections happened to route through fra or gig. Fly’s own resolution notes attribute the root cause to a planned Upstash maintenance window where replicas weren’t properly drained before being returned to service. Fly committed to additional tooling and upgrade-safety checks afterward.

Elevated errors creating apps and managing secrets — October 15, minor (per Fly’s classification). Between 06:40 and 09:50 UTC, app creation and secrets requests failed or timed out — Fly’s own update specifies this affected flyctl, the Machines API, and the dashboard with 500 or 503 errors on these specific operations. Fly is explicit that running apps and Machines were not affected; this was about creating new things and changing secrets, not about anything already deployed. That’s roughly three hours and ten minutes where a team trying to rotate a secret or spin up a new app during a deploy would have hit failures — minor by Fly’s own severity scale, but a real window of friction for anyone whose timing happened to land inside it.

Platform Wide Rolling Host Reboots — October 16–17, major. Starting at 16:22 UTC on the 16th and completing by 05:15 UTC the next day — roughly 13 hours end to end — Fly rolled restarts across its entire host fleet as what its own incident update describes as a mitigation for “PwnEscape (Linux Kernel CVE-2026-99999).” Each host was unavailable for 15 to 20 minutes during its own restart window, with Fly’s updates noting progress in percentage terms (25%, 50%, 70%, 90%, 95% of the fleet restarted) as the rollout worked through region after region. Customer Machines, volumes, and managed Postgres cluster instances were unavailable on whichever host was mid-restart at any given moment — meaning the specific apps affected, and when, depended entirely on which host they happened to run on, not on anything the customer did.

Degraded Edge Performance — October 22, classified “none” impact by Fly, but real. Between roughly 18:00 and 18:10 UTC, multiple regions saw elevated dropped connections and longer-than-usual connection times reaching apps. Ten minutes, fixed, moved on — but it’s the kind of incident that shows up as “my app felt slow for a few minutes for no reason I could find in my own logs,” because the cause wasn’t in the customer’s logs at all.

Beyond these four, the same seven-week window includes: a GRU-region capacity incident affecting machine creation and remote builds (October 20), a Grafana dashboard outage for fly-metrics.net (October 16), delayed historical log ingestion (October 13), a sprite-hosting certificate issue (October 11–12), a critical-severity sprite-creation failure (October 8), major LHR network issues (October 8), an AMS partial outage classified critical (October 3), a GRU state-database migration issue (September 24), a 6PN private-networking incident (September 24), a DFW IPv6 issue (September 23), an AMS network outage classified critical (September 26), and more. The full list is public and dated on Fly’s own status page.

Why does Fly.io have so many incidents?

Not because Fly.io’s engineering is weak — the opposite framing is closer to true. Fly operates a genuinely global, multi-tenant edge network: dozens of regions, a shared private networking layer (6PN), shared managed Postgres clusters, a shared build system, and a fleet of physical and virtual hosts that customer workloads are packed onto to make the whole thing affordable and fast. That architecture is what makes Fly’s actual pitch — run your app close to users anywhere, without provisioning regional infrastructure yourself — possible at all. It also means that any one of those shared layers degrading (a regional network link, a shared Redis provider’s maintenance window, a kernel vulnerability forcing a fleet-wide reboot) surfaces as an incident that’s visible on a public status page, dated and timestamped, because it’s a single shared system with many tenants watching the same dashboard.

A platform-wide kernel CVE is the clearest example: when a vulnerability serious enough to warrant immediate remediation is found, Fly has to restart every host in the fleet, on Fly’s schedule, because the hosts are Fly’s infrastructure, shared across all its tenants. Every customer running on an affected host experiences that restart whether or not patching it was something they would have chosen to do at that moment, on that day, with that urgency.

What this honestly means, and doesn’t mean

Fly.io is, by most independent accounts and by its own transparent status history, a generally reliable platform — the point of listing 25 incidents in seven weeks is not that this is an unusual rate of failure for a global multi-tenant network; it’s genuinely normal for one, and transparent reporting of that rate is a point in Fly’s favor, not against it. Most of these incidents are regional, short, and classified minor or none. None of them is remotely the scale of Railway’s security incident or Vercel’s six-and-a-half-hour build outage. The honest framing is narrower than “Fly is unreliable”: it’s that a shared multi-tenant edge network accumulates incidents that don’t affect every customer the same way a single dedicated server’s own uptime does.

A server you own and operate has exactly one uptime record: its own. It doesn’t go down because a Redis provider in a different metro mishandled a maintenance window that happened to route your traffic through it. It doesn’t restart on a schedule set by someone else’s kernel-patching urgency, for a vulnerability that may or may not apply to your own configuration — you choose when to patch your own kernel, on your own timeline, having assessed your own exposure. It isn’t affected by a capacity constraint in a region three time zones away because that region happens to share infrastructure with yours.

What you give up is exactly what Fly sells: the global anycast network, the ability to spin up a Machine in Tokyo and another in Frankfurt without owning either piece of hardware, and the operational work of running that footprint yourself if you wanted the same geographic spread. A single owned server has one location, one capacity ceiling, and one person (you) responsible for patching its kernel on your own schedule — which is real freedom, and also a real obligation that a managed edge network takes off your plate. Neither model is strictly better; they’re different answers to how much of that operational surface you want to own versus rent, the same tradeoff that runs through this entire category.

What this means for you

• If your app is genuinely latency-sensitive across multiple global regions, a multi-tenant edge network like Fly’s is doing real, hard infrastructure work that would be expensive to replicate on owned servers — that’s a legitimate reason to accept shared-infrastructure risk in exchange for it.
• If your app serves one audience from one or two regions, a dedicated server’s independent uptime record may be the better trade — you’re not paying (in risk or in dollars) for global reach you don’t need.
• Read a platform’s own public status history before committing to it, specifically for the pattern (frequency, typical duration, which services) rather than any single incident — a transparent, frequently-updated status page is itself a signal worth taking seriously, in either direction.
• Know which layer actually failed when something goes wrong — “my app was slow” diagnosed as a regional edge-performance blip you can’t fix yourself is a different problem than “my own server’s disk filled up,” which you can.

See the full comparison: Railyard vs. Fly.io, and the complete migration walkthrough: Migrating from Fly.io.

FAQ

Is Fly.io down right now? This post covers a historical pattern from September and October 2026, not real-time status. Check Fly.io’s own status page directly for current incidents.

Why does Fly.io have so many status-page incidents? Fly operates a global, multi-tenant edge network — shared regional infrastructure, shared managed databases, and a shared host fleet. Any degradation in one of those shared layers (a regional network issue, a database provider’s maintenance window, a fleet-wide kernel patch) shows up as a dated incident on a status page that every tenant can see, which is a function of operating shared infrastructure transparently, not necessarily a sign of worse engineering.

What was the Fly.io Redis outage in September 2026? On September 23, 2026, Fly’s status page reported Upstash Redis unavailability in the FRA region from about 12:00 to 13:05 UTC, caused by replicas not draining properly during a planned maintenance upgrade. It affected databases hosted in or routed through the fra/gig regions.

Does hosting on your own server avoid these kinds of incidents? It removes exposure to Fly’s specific shared layers — its regional network, its managed Redis partner, its host-patching schedule — in exchange for giving up Fly’s global multi-region edge network, which would be expensive to replicate yourself. A single owned server has its own, independent uptime record, for better and for worse.

Sources

• Fly.io Status — incident history — Fly.io’s own status page
• Fly.io Status incidents API — Fly.io’s own public incident data for all incidents cited above, with exact timestamps and impact classifications