Fly.ios Incident-Muster im September und Oktober 2026, verifiziert gegen die eigene Statusseite

Fly.io hat für diesen Zeitraum keinen einzelnen schlagzeilentauglichen Ausfall vorzuweisen — nichts wie einen mehrtägigen Plattformkollaps. Was es hat, sichtbar auf der eigenen öffentlichen Statusseite, ist ein stetiger Rhythmus: 25 einzelne Incidents zwischen dem 2. September und dem 22. Oktober 2026, über bestimmte Regionen, bestimmte Dienste und eine Spanne von Schweregraden von „none” bis „critical”. Dieses Muster, nicht ein einzelnes Ereignis, ist die eigentliche Geschichte, und es lohnt sich, direkt hinzuschauen statt durch die Zusammenfassung von jemand anderem.

Was Fly.ios eigene Status-Historie zeigt

Alles Folgende stammt aus Fly.ios eigener Incident-Historie unter status.flyio.net, gelesen über die öffentliche Incident-API, mit Flys eigenen Zeitstempeln und Impact-Klassifizierungen.

Upstash-Nichtverfügbarkeit in der FRA-Region — 23. September, major. Von etwa 12:00 bis 13:05 UTC bekamen Clients Connection-Timeouts zu Redis-Datenbanken in den Regionen fra oder gig, und zu Datenbanken anderswo, deren Verbindungen zufällig über fra oder gig geroutet wurden. Flys eigene Resolution-Notizen führen die Grundursache auf ein geplantes Upstash-Maintenance-Fenster zurück, bei dem Replicas nicht ordnungsgemäß geleert wurden, bevor sie wieder in Betrieb genommen wurden. Fly verpflichtete sich danach zu zusätzlichem Tooling und Upgrade-Sicherheitschecks.

Erhöhte Fehler beim Erstellen von Apps und Verwalten von Secrets — 15. Oktober, minor (nach Flys Klassifizierung). Zwischen 06:40 und 09:50 UTC schlugen App-Erstellungs- und Secrets-Requests fehl oder liefen in Timeouts — Flys eigenes Update spezifiziert, dass dies flyctl, die Machines API und das Dashboard mit 500- oder 503-Fehlern auf diesen spezifischen Operationen betroffen hat. Fly ist explizit, dass laufende Apps und Machines nicht betroffen waren; es ging um das Erstellen neuer Dinge und das Ändern von Secrets, nicht um etwas bereits Deployetes. Das sind etwa drei Stunden und zehn Minuten, in denen ein Team, das versucht, ein Secret zu rotieren oder eine neue App während eines Deploys hochzuziehen, auf Fehler gestoßen wäre — minor nach Flys eigener Schweregrad-Skala, aber ein echtes Fenster der Reibung für jeden, dessen Timing zufällig hineinfiel.

Plattformweite rollierende Host-Reboots — 16.–17. Oktober, major. Beginnend um 16:22 UTC am 16. und abgeschlossen bis 05:15 UTC am nächsten Tag — etwa 13 Stunden insgesamt — rollte Fly Restarts über die gesamte Host-Flotte als das, was das eigene Incident-Update als Mitigation für „PwnEscape (Linux Kernel CVE-2026-99999)” beschreibt. Jeder Host war während seines eigenen Restart-Fensters 15 bis 20 Minuten nicht verfügbar, wobei Flys Updates den Fortschritt in Prozentzahlen vermerkten (25 %, 50 %, 70 %, 90 %, 95 % der Flotte neu gestartet), während sich der Rollout Region für Region durcharbeitete. Kunden-Machines, Volumes und verwaltete Postgres-Cluster-Instanzen waren nicht verfügbar, je nachdem, welcher Host gerade mitten im Neustart war — das heißt, welche spezifischen Apps betroffen waren, und wann, hing vollständig davon ab, auf welchem Host sie zufällig liefen, nicht von irgendetwas, das der Kunde getan hatte.

Degraded Edge Performance — 22. Oktober, von Fly als „none” Impact klassifiziert, aber real. Zwischen etwa 18:00 und 18:10 UTC sahen mehrere Regionen erhöhte abgebrochene Verbindungen und längere als übliche Verbindungszeiten zu Apps. Zehn Minuten, behoben, weiter — aber es ist die Art von Incident, die als „meine App fühlte sich für ein paar Minuten langsam an, ohne dass ich in meinen eigenen Logs einen Grund finden konnte” auftaucht, weil die Ursache gar nicht in den Logs des Kunden lag.

Über diese vier hinaus umfasst dasselbe Siebenwochen-Fenster: einen GRU-Region-Kapazitätsincident, der die Machine-Erstellung und Remote-Builds betraf (20. Oktober), einen Grafana-Dashboard-Ausfall für fly-metrics.net (16. Oktober), verzögerte historische Log-Ingestion (13. Oktober), ein Sprite-Hosting-Zertifikatsproblem (11.–12. Oktober), einen kritischen Sprite-Erstellungsfehler (8. Oktober), größere LHR-Netzwerkprobleme (8. Oktober), einen als kritisch klassifizierten partiellen AMS-Ausfall (3. Oktober), ein GRU-State-Database-Migrationsproblem (24. September), einen 6PN-Private-Networking-Incident (24. September), ein DFW-IPv6-Problem (23. September), einen als kritisch klassifizierten AMS-Netzwerkausfall (26. September), und mehr. Die vollständige Liste ist öffentlich und datiert auf Flys eigener Statusseite.

Warum hat Fly.io so viele Incidents?

Nicht, weil Fly.ios Engineering schwach ist — das Gegenteil ist eher wahr. Fly betreibt ein wirklich globales Multi-Tenant-Edge-Netzwerk: Dutzende Regionen, eine geteilte Private-Networking-Schicht (6PN), geteilte verwaltete Postgres-Cluster, ein geteiltes Build-System und eine Flotte physischer und virtueller Hosts, auf die Kunden-Workloads gepackt werden, um das Ganze erschwinglich und schnell zu machen. Diese Architektur ist es, was Flys eigentlichen Pitch überhaupt erst möglich macht — deine App überall nah an den Nutzern laufen zu lassen, ohne regionale Infrastruktur selbst bereitzustellen. Es bedeutet auch, dass jede Verschlechterung einer dieser geteilten Schichten (eine regionale Netzwerkverbindung, das Maintenance-Fenster eines geteilten Redis-Anbieters, eine Kernel-Schwachstelle, die einen flottenweiten Reboot erzwingt) als Incident auftaucht, der auf einer öffentlichen Statusseite sichtbar ist, datiert und mit Zeitstempel, weil es ein einzelnes geteiltes System mit vielen Tenants ist, die auf dasselbe Dashboard schauen.

Eine plattformweite Kernel-CVE ist das klarste Beispiel: Wenn eine Schwachstelle gefunden wird, die ernst genug für sofortige Behebung ist, muss Fly jeden Host in der Flotte neu starten, nach Flys Zeitplan, weil die Hosts Flys Infrastruktur sind, geteilt über alle Tenants. Jeder Kunde, der auf einem betroffenen Host läuft, erlebt diesen Restart, egal ob das Patchen in diesem Moment, an diesem Tag, mit dieser Dringlichkeit etwas gewesen wäre, das er selbst gewählt hätte.

Was das ehrlich bedeutet, und was nicht

Fly.io ist, nach den meisten unabhängigen Berichten und nach seiner eigenen transparenten Status-Historie, eine generell zuverlässige Plattform — der Punkt, 25 Incidents in sieben Wochen aufzulisten, ist nicht, dass das eine ungewöhnliche Ausfallrate für ein globales Multi-Tenant-Netzwerk ist; es ist für eines wirklich normal, und transparente Berichterstattung über diese Rate spricht für Fly, nicht gegen es. Die meisten dieser Incidents sind regional, kurz, und als minor oder none klassifiziert. Keiner davon ist im Entferntesten so groß wie Railways Sicherheitsincident oder Vercels sechseinhalbstündiger Build-Ausfall. Die ehrliche Einordnung ist enger als „Fly ist unzuverlässig”: Es ist, dass ein geteiltes Multi-Tenant-Edge-Netzwerk Incidents anhäuft, die nicht jeden Kunden auf dieselbe Weise betreffen, wie es die eigene Uptime eines einzelnen dedizierten Servers tut.

Ein Server, den du selbst besitzt und betreibst, hat genau eine Uptime-Bilanz: seine eigene. Er fällt nicht aus, weil ein Redis-Anbieter in einer anderen Metropole ein Maintenance-Fenster schlecht gehandhabt hat, das zufällig deinen Traffic durchroutete. Er startet nicht nach einem Zeitplan neu, der von der Dringlichkeit des Kernel-Patchings eines anderen festgelegt wird, für eine Schwachstelle, die auf deine eigene Konfiguration zutreffen mag oder nicht — du entscheidest, wann du deinen eigenen Kernel patchst, nach deinem eigenen Zeitplan, nachdem du deine eigene Exposition bewertet hast. Er ist nicht von einem Kapazitätsengpass in einer drei Zeitzonen entfernten Region betroffen, nur weil diese Region zufällig Infrastruktur mit deiner teilt.

Was du dafür aufgibst, ist genau das, was Fly verkauft: das globale Anycast-Netzwerk, die Fähigkeit, eine Machine in Tokio und eine andere in Frankfurt hochzuziehen, ohne eine der beiden Hardware-Stücke zu besitzen, und die operative Arbeit, diesen Footprint selbst zu betreiben, wenn du dieselbe geografische Streuung wolltest. Ein einzelner eigener Server hat einen Standort, eine Kapazitätsdecke, und eine Person (dich), die für das Patchen seines Kernels nach deinem eigenen Zeitplan zuständig ist — was echte Freiheit ist, und auch eine echte Verpflichtung, die dir ein verwaltetes Edge-Netzwerk vom Tisch nimmt. Kein Modell ist strikt besser; sie sind unterschiedliche Antworten darauf, wie viel von dieser operativen Fläche du besitzen statt mieten willst, derselbe Tradeoff, der sich durch diese ganze Kategorie zieht.

Was das für dich bedeutet

• Wenn deine App wirklich latenzsensitiv über mehrere globale Regionen hinweg ist, leistet ein Multi-Tenant-Edge-Netzwerk wie Flys echte, harte Infrastrukturarbeit, die auf eigenen Servern teuer zu replizieren wäre — das ist ein legitimer Grund, geteiltes Infrastrukturrisiko dafür in Kauf zu nehmen.
• Wenn deine App eine Zielgruppe aus einer oder zwei Regionen bedient, könnte die unabhängige Uptime-Bilanz eines dedizierten Servers der bessere Deal sein — du zahlst nicht (in Risiko oder in Geld) für globale Reichweite, die du nicht brauchst.
• Lies die eigene öffentliche Status-Historie einer Plattform, bevor du dich dafür entscheidest, speziell auf das Muster (Häufigkeit, typische Dauer, welche Dienste) achtend statt auf einen einzelnen Incident — eine transparente, häufig aktualisierte Statusseite ist selbst ein Signal, das es wert ist, ernst genommen zu werden, in beide Richtungen.
• Wisse, welche Schicht tatsächlich ausgefallen ist, wenn etwas schiefgeht — „meine App war langsam”, diagnostiziert als regionaler Edge-Performance-Blip, den du selbst nicht beheben kannst, ist ein anderes Problem als „die Disk meines eigenen Servers lief voll”, was du kannst.

Sieh den vollständigen Vergleich: Railyard vs. Fly.io, und die vollständige Migrations-Anleitung: Migrating from Fly.io.

FAQ

Ist Fly.io gerade down? Dieser Beitrag deckt ein historisches Muster aus September und Oktober 2026 ab, nicht Echtzeit-Status. Prüfe Fly.ios eigene Statusseite direkt für aktuelle Incidents.

Warum hat Fly.io so viele Statusseiten-Incidents? Fly betreibt ein globales Multi-Tenant-Edge-Netzwerk — geteilte regionale Infrastruktur, geteilte verwaltete Datenbanken und eine geteilte Host-Flotte. Jede Verschlechterung einer dieser geteilten Schichten (ein regionales Netzwerkproblem, das Maintenance-Fenster eines Datenbankanbieters, ein flottenweiter Kernel-Patch) taucht als datierter Incident auf einer Statusseite auf, die jeder Tenant sehen kann, was eine Funktion davon ist, geteilte Infrastruktur transparent zu betreiben, nicht notwendigerweise ein Zeichen schlechteren Engineerings.

Was war der Fly.io-Redis-Ausfall im September 2026? Am 23. September 2026 meldete Flys Statusseite Upstash-Redis-Nichtverfügbarkeit in der FRA-Region von etwa 12:00 bis 13:05 UTC, verursacht dadurch, dass Replicas während eines geplanten Maintenance-Upgrades nicht ordnungsgemäß geleert wurden. Betroffen waren Datenbanken, die in den Regionen fra/gig gehostet wurden oder darüber geroutet wurden.

Vermeidet Hosting auf dem eigenen Server diese Art von Incidents? Es entfernt die Exposition gegenüber Flys spezifischen geteilten Schichten — seinem regionalen Netzwerk, seinem verwalteten Redis-Partner, seinem Host-Patching-Zeitplan — im Austausch dafür, Flys globales Multi-Region-Edge-Netzwerk aufzugeben, das selbst zu replizieren teuer wäre. Ein einzelner eigener Server hat seine eigene, unabhängige Uptime-Bilanz, im Guten wie im Schlechten.

Quellen

• Fly.io Status — incident history — Fly.ios eigene Statusseite
• Fly.io Status incidents API — Fly.ios eigene öffentliche Incident-Daten für alle oben zitierten Incidents, mit exakten Zeitstempeln und Impact-Klassifizierungen