Le pattern d'incidents de Fly.io de septembre à octobre 2026, vérifié sur leur propre page de statut

Fly.io n’a pas une seule panne spectaculaire à pointer du doigt pour cette période — rien comme un effondrement de plateforme sur plusieurs jours. Ce qu’elle a, visible sur sa propre page de statut publique, c’est une cadence soutenue : 25 incidents distincts entre le 2 septembre et le 22 octobre 2026, touchant des régions précises, des services précis, et une gamme de sévérités allant de « aucune » à « critique ». Ce pattern, pas un seul événement, est la vraie histoire, et ça vaut la peine de le regarder directement plutôt qu’à travers le résumé de quelqu’un d’autre.

Ce que montre le propre historique de statut de Fly.io

Tout ce qui suit vient de l’historique d’incidents propre de Fly.io sur status.flyio.net, lu via son API publique d’incidents, avec les propres horodatages et classifications d’impact de Fly.

Indisponibilité Upstash dans la région FRA — 23 septembre, majeur. De 12 h à 13 h 05 UTC environ, des clients ont eu des délais de connexion vers des bases de données Redis hébergées dans les régions fra ou gig, et vers des bases ailleurs dont les connexions passaient par fra ou gig. Les propres notes de résolution de Fly attribuent la cause racine à une fenêtre de maintenance planifiée chez Upstash où des répliques n’ont pas été correctement drainées avant d’être remises en service. Fly s’est engagée à ajouter des outils et des vérifications de sécurité pour les mises à niveau par la suite.

Erreurs accrues lors de la création d’apps et de la gestion de secrets — 15 octobre, mineur (selon la classification de Fly). Entre 6 h 40 et 9 h 50 UTC, les demandes de création d’apps et de gestion de secrets ont échoué ou expiré — la propre mise à jour de Fly précise que ça a touché flyctl, l’API Machines, et le tableau de bord avec des erreurs 500 ou 503 sur ces opérations précises. Fly est explicite : les apps et Machines déjà en cours d’exécution n’ont pas été touchées; c’était à propos de créer de nouvelles choses et de changer des secrets, pas de quoi que ce soit déjà déployé. C’est environ trois heures et dix minutes où une équipe essayant de faire tourner un secret ou de démarrer une nouvelle app pendant un déploiement aurait rencontré des échecs — mineur selon l’échelle de sévérité de Fly, mais une vraie fenêtre de friction pour quiconque avait le mauvais moment.

Redémarrages progressifs de tous les hôtes de la plateforme — 16-17 octobre, majeur. À partir de 16 h 22 UTC le 16 et complété à 5 h 15 UTC le lendemain — environ 13 heures au total — Fly a effectué des redémarrages progressifs sur l’ensemble de sa flotte d’hôtes, décrit par sa propre mise à jour d’incident comme une mesure d’atténuation pour « PwnEscape (Linux Kernel CVE-2026-99999) ». Chaque hôte était indisponible de 15 à 20 minutes pendant son propre redémarrage, les mises à jour de Fly notant la progression en pourcentage (25 %, 50 %, 70 %, 90 %, 95 % de la flotte redémarrée) à mesure que le déploiement progressait région par région. Les Machines, volumes et instances de grappes Postgres gérées des clients étaient indisponibles sur l’hôte en cours de redémarrage à un moment donné — ce qui veut dire que les apps précises touchées, et quand, dépendaient entièrement de l’hôte sur lequel elles tournaient, pas de quoi que ce soit que le client avait fait.

Performance de bordure dégradée — 22 octobre, classé impact « aucun » par Fly, mais réel. Entre environ 18 h et 18 h 10 UTC, plusieurs régions ont connu des connexions abandonnées accrues et des temps de connexion plus longs qu’habituellement pour atteindre les apps. Dix minutes, corrigé, passé à autre chose — mais c’est le genre d’incident qui se manifeste par « mon app semblait lente pendant quelques minutes sans raison que je pouvais trouver dans mes propres journaux », parce que la cause n’était pas du tout dans les journaux du client.

Au-delà de ces quatre, la même fenêtre de sept semaines inclut : un incident de capacité dans la région GRU touchant la création de machines et les builds distants (20 octobre), une panne du tableau de bord Grafana pour fly-metrics.net (16 octobre), un retard dans l’ingestion des journaux historiques (13 octobre), un problème de certificat pour l’hébergement sprite (11-12 octobre), un échec de création sprite classé critique (8 octobre), des problèmes réseau majeurs à LHR (8 octobre), une panne partielle à AMS classée critique (3 octobre), un problème de migration de base de données d’état à GRU (24 septembre), un incident de réseautage privé 6PN (24 septembre), un problème IPv6 à DFW (23 septembre), une panne réseau à AMS classée critique (26 septembre), et plus encore. La liste complète est publique et datée sur la propre page de statut de Fly.

Pourquoi Fly.io a-t-elle autant d’incidents?

Pas parce que l’ingénierie de Fly.io est faible — c’est plutôt le contraire qui est vrai. Fly exploite un réseau de bordure véritablement mondial et multi-locataire : des dizaines de régions, une couche de réseautage privé partagée (6PN), des grappes Postgres gérées partagées, un système de build partagé, et une flotte d’hôtes physiques et virtuels sur lesquels les charges de travail des clients sont empaquetées pour rendre le tout abordable et rapide. Cette architecture est ce qui rend le propre argument de vente de Fly — faire tourner votre app près des utilisateurs n’importe où, sans provisionner d’infrastructure régionale vous-même — possible tout court. Ça veut aussi dire qu’une dégradation de l’une de ces couches partagées (un lien réseau régional, la fenêtre de maintenance d’un fournisseur Redis partagé, une vulnérabilité de noyau forçant un redémarrage de toute la flotte) se manifeste comme un incident visible sur une page de statut publique, daté et horodaté, parce que c’est un seul système partagé avec plusieurs locataires regardant le même tableau de bord.

Une CVE de noyau à l’échelle de la plateforme en est l’exemple le plus clair : quand une vulnérabilité assez sérieuse pour justifier une remédiation immédiate est découverte, Fly doit redémarrer chaque hôte de la flotte, selon l’échéancier de Fly, parce que les hôtes sont l’infrastructure de Fly, partagée entre tous ses locataires. Chaque client tournant sur un hôte touché vit ce redémarrage, qu’il aurait choisi ou non de le corriger à ce moment-là, ce jour-là, avec cette urgence.

Ce que ça signifie honnêtement, et ce que ça ne signifie pas

Fly.io est, selon la plupart des comptes indépendants et son propre historique de statut transparent, une plateforme généralement fiable — le but de lister 25 incidents en sept semaines n’est pas que c’est un taux de défaillance inhabituel pour un réseau mondial multi-locataire; c’est en fait normal pour ce genre de réseau, et un rapport transparent de ce taux est un point en faveur de Fly, pas contre. La plupart de ces incidents sont régionaux, courts, et classés mineurs ou nuls. Aucun n’approche l’ampleur de l’incident de sécurité de Railway ou de la panne de build de six heures et demie chez Vercel. Le cadrage honnête est plus étroit que « Fly n’est pas fiable » : c’est qu’un réseau de bordure partagé et multi-locataire accumule des incidents qui ne touchent pas chaque client de la même façon que le propre temps de disponibilité d’un seul serveur dédié.

Un serveur que vous possédez et exploitez a exactement un seul historique de disponibilité : le sien. Il ne tombe pas parce qu’un fournisseur Redis dans une autre métropole a mal géré une fenêtre de maintenance par laquelle votre trafic passait par hasard. Il ne redémarre pas selon un échéancier fixé par l’urgence de correction de noyau de quelqu’un d’autre, pour une vulnérabilité qui peut ou non s’appliquer à votre propre configuration — vous choisissez quand corriger votre propre noyau, selon votre propre échéancier, après avoir évalué votre propre exposition. Il n’est pas touché par une contrainte de capacité dans une région à trois fuseaux horaires de distance parce que cette région partage l’infrastructure avec la vôtre.

Ce que vous perdez, c’est exactement ce que Fly vend : le réseau anycast mondial, la capacité de démarrer une Machine à Tokyo et une autre à Francfort sans posséder ni l’un ni l’autre matériel, et le travail opérationnel d’exploiter cette empreinte vous-même si vous vouliez la même portée géographique. Un seul serveur possédé a un emplacement, un plafond de capacité, et une seule personne (vous) responsable de corriger son noyau selon votre propre échéancier — ce qui est une vraie liberté, et aussi une vraie obligation qu’un réseau de bordure géré retire de vos épaules. Aucun modèle n’est strictement meilleur; ce sont des réponses différentes à combien de cette surface opérationnelle vous voulez posséder par rapport à louer, le même compromis qui traverse toute cette catégorie.

Ce que ça signifie pour vous

• Si votre app est véritablement sensible à la latence sur plusieurs régions mondiales, un réseau de bordure multi-locataire comme celui de Fly fait un vrai travail d’infrastructure difficile qui serait coûteux à reproduire sur des serveurs possédés — c’est une raison légitime d’accepter le risque d’infrastructure partagée en échange.
• Si votre app sert un seul public depuis une ou deux régions, le propre historique de disponibilité indépendant d’un serveur dédié peut être le meilleur compromis — vous ne payez pas (en risque ou en dollars) pour une portée mondiale dont vous n’avez pas besoin.
• Lisez l’historique de statut public propre d’une plateforme avant de vous y engager, précisément pour le pattern (fréquence, durée typique, quels services) plutôt que pour un seul incident — une page de statut transparente et fréquemment mise à jour est elle-même un signal à prendre au sérieux, dans un sens comme dans l’autre.
• Sachez quelle couche a réellement échoué quand quelque chose ne va pas — « mon app était lente » diagnostiqué comme un accroc régional de performance de bordure que vous ne pouvez pas corriger vous-même est un problème différent de « le disque de mon propre serveur était plein », que vous pouvez corriger.

Voyez la comparaison complète : Railyard contre Fly.io, et le parcours de migration complet : Migrer depuis Fly.io.

Foire aux questions

Fly.io est-elle en panne en ce moment? Ce billet couvre un pattern historique de septembre et octobre 2026, pas un statut en temps réel. Vérifiez directement la propre page de statut de Fly.io pour les incidents actuels.

Pourquoi Fly.io a-t-elle autant d’incidents sur sa page de statut? Fly exploite un réseau de bordure mondial et multi-locataire — infrastructure régionale partagée, bases de données gérées partagées, et une flotte d’hôtes partagée. Toute dégradation dans l’une de ces couches partagées (un problème réseau régional, la fenêtre de maintenance d’un fournisseur de base de données, un correctif de noyau à l’échelle de la flotte) se manifeste comme un incident daté sur une page de statut que chaque locataire peut voir, ce qui est une fonction de l’exploitation transparente d’une infrastructure partagée, pas nécessairement un signe d’une moins bonne ingénierie.

Qu’est-ce que la panne Redis de Fly.io en septembre 2026? Le 23 septembre 2026, la page de statut de Fly a rapporté une indisponibilité Redis Upstash dans la région FRA de 12 h à 13 h 05 UTC environ, causée par des répliques mal drainées pendant une mise à niveau de maintenance planifiée. Ça a touché les bases de données hébergées dans ou acheminées par les régions fra/gig.

Héberger sur son propre serveur évite-t-il ce genre d’incidents? Ça élimine l’exposition aux couches partagées précises de Fly — son réseau régional, son partenaire Redis géré, son échéancier de correction d’hôtes — en échange de renoncer au réseau de bordure multi-régions mondial de Fly, qui serait coûteux à reproduire vous-même. Un seul serveur possédé a son propre historique de disponibilité indépendant, pour le meilleur et pour le pire.

Sources

• Fly.io Status — historique des incidents — propre page de statut de Fly.io
• API des incidents de Fly.io Status — propres données publiques d’incidents de Fly.io pour tous les incidents cités ci-dessus, avec horodatages exacts et classifications d’impact