Incident Fly.io résolu
(status.flyio.net)- La page de statut de Fly.io indique actuellement All Systems Operational ; les principaux composants, dont l’exécution des apps, le dashboard, l’API Machines et la disponibilité régionale, sont opérationnels
- L’incident Elevated API Errors du 1er juillet 2026 a été résolu à 07:50 UTC après correction des erreurs de l’API GraphQL et des problèmes de traitement des tâches en arrière-plan
- L’incident Delayed Metrics du 30 juin a entraîné des métriques retardées ou manquantes dans le dashboard fly-metrics.net pour certains clients ; le service est revenu à la normale après traitement du backlog et augmentation de la capacité
- Cette page de statut est destinée aux mises à jour sur les incidents globaux et n’inclut pas les pannes matérielles à impact limité ni les événements d’infrastructure isolés
- Les impacts propres à chaque app doivent être consultés sur la personalized status page du dashboard Fly Organization ; les incidents internes et l’activité sont indiqués dans l’Infra Log
État actuel du service
- La page de statut de Fly.io indique actuellement All Systems Operational
- Les principaux éléments indiqués comme opérationnels sont Customer Applications, Dashboard, Machines API, Regional Availability, Persistent Storage (Volumes), Deployments, Remote Builds, Logs, Metrics, SSL/TLS Certificate Provisioning, UDP Anycast, Fly Machine Image Registry 1·2, Extensions, Upstash for Redis, DNS, Billing et Managed Postgres
- Les régions sont également indiquées comme opérationnelles : AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD et YYZ
Périmètre de la page de statut
- Cette page est destinée aux mises à jour sur les global incidents
- Elle n’inclut pas les mises à jour concernant les pannes matérielles courantes à impact limité ni les événements d’infrastructure isolés
- Une vue personnalisée de tous les événements susceptibles d’affecter une app est disponible sur la personalized status page du dashboard Fly Organization
- Les incidents internes et les autres activités sont à consulter dans l’Infra Log
1er juillet 2026 : Elevated API Errors
- Elevated API Errors a été marqué Resolved le 1er juillet à 07:50 UTC
- À 06:14 UTC, une enquête a été ouverte sur des elevated errors dans l’API GraphQL et le traitement des tâches en arrière-plan
- À 06:27 UTC, la cause a été identifiée et un correctif était en cours
- À 07:05 UTC, le correctif a été appliqué et les elevated API errors n’étaient plus observées
- Certaines opérations du dashboard pouvaient être retardées pendant que le traitement en arrière-plan rattrapait son retard
- À 07:26 UTC, les tâches en arrière-plan avaient rattrapé leur retard et la surveillance s’est poursuivie alors que l’API était pleinement opérationnelle
30 juin 2026 : Delayed Metrics et IP egress SIN/NRT
- Delayed Metrics a été résolu le 30 juin à 22:19 UTC
- Un problème a touché les métriques clients dans le dashboard fly-metrics.net, et les utilisateurs pouvaient voir des métriques retardées ou manquantes
- Des problèmes sur plusieurs hôtes ont retardé la collecte des métriques, et une resource contention sur certains metrics ingestion hosts a été traitée comme cause
- Le débit de traitement du metrics cluster a été augmenté pour traiter le backlog, avec un rééquilibrage de l’ingestion traffic et l’ajout de capacité de traitement supplémentaire
- Le 30 juin à 19:58 UTC, presque toutes les métriques avaient rattrapé leur retard, mais un petit nombre de métriques de
sinetsydrestaient encore à traiter - Egress IP issues in SIN and NRT a été résolu le 30 juin à 14:03 UTC
- Certaines Machines utilisant des IP egress à SIN et NRT ont pu perdre temporairement leur connexion ou subir une dégradation des performances
26–25 juin 2026 : incidents réseau, déploiement et control plane
- IPv6 Connectivity Issues in EWR a été résolu le 26 juin à 23:48 UTC
- Un problème de connectivité réseau IPv6 chez un upstream provider s’est produit à EWR
- Les apps ayant des Machines sur les hôtes affectés pouvaient voir leur connectivité vers certaines destinations IPv6 affectée
- Network maintenance in YYZ était une maintenance planifiée menée le 26 juin de 08:00 à 09:00 UTC, désormais terminée
- Une perte de connexion pouvant atteindre 15 minutes était attendue pendant la fenêtre de maintenance
- Deploys defaulting to Fly-hosted Builders a été résolu le 25 juin à 15:38 UTC
- Pendant l’enquête sur les retards de provisioning des builders adossés à Depot, la stratégie par défaut de
fly deploya basculé vers les Fly-hosted builders - Les utilisateurs pouvaient forcer les déploiements basés sur Depot avec
fly deploy --depot=true, puis les déploiements basés sur les builders Fly avecfly deploy --depot=false
- Pendant l’enquête sur les retards de provisioning des builders adossés à Depot, la stratégie par défaut de
- Elevated control plane latency a été résolu le 25 juin à 15:18 UTC
- Une latence et une saturation du control plane ont touché les régions BOM et NRT
- Les apps ayant des Machines dans ces régions pouvaient subir des temps de réponse plus longs et d’éventuelles 502 errors
24–17 juin 2026 : réseau en Amérique du Nord et SIN/NRT, recherche de logs
- Degraded networking in North America a été résolu le 24 juin à 06:57 UTC
- Une dégradation des performances réseau entre sites nord-américains a fait l’objet d’une enquête à la suite d’un incident upstream
- Certaines Machines pouvaient constater des pertes de paquets et une latence plus élevée sur certains chemins
- Une partie du trafic 6PN Private Networking entrant ou sortant de la région LAX restait affectée
- Network issues in SIN, NRT a été résolu le 22 juin à 21:56 UTC
- Un upstream provider a rencontré des problèmes réseau dans les régions SIN et NRT, et les apps de ces régions pouvaient être injoignables ou subir une forte perte de paquets
- SIN, NRT network issues a été résolu le 22 juin à 19:48 UTC
- L’incident a d’abord été investigué comme un problème réseau upstream dans la région SIN, puis les apps de la région NRT ont également pu rencontrer des problèmes pour atteindre certaines destinations
- Log search unavailable a été résolu le 19 juin à 21:53 UTC
- L’incident a affecté les panels de recherche de logs Fly Metrics et les historical application logs retournés initialement par la commande
fly logs - Le streaming de
fly logs, la page Live Logs du dashboard et les Fly Log Shipper services fonctionnaient normalement - Après correction, les historical logs ont été backfill et la plupart des queued historical logs sont devenus consultables
- L’incident a affecté les panels de recherche de logs Fly Metrics et les historical application logs retournés initialement par la commande
- Network Issues in SIN a été résolu le 17 juin à 04:55 UTC
- Un problème de connectivité réseau touchait la région SIN et les hosted apps pouvaient être indisponibles
- Certaines Machines étaient injoignables, et certains clusters Managed Postgres pouvaient échouer lors d’un fail-over ou d’une update
1 commentaires
Avis sur Hacker News
Mon site web hébergé sur fly.io est tombé pendant 5 minutes il y a environ 6 heures, puis il est revenu aussitôt, et depuis tout fonctionne normalement.
Le service de monitoring gratuit vérifie toutes les 5 minutes, donc il a peut-être raté des interruptions plus courtes, mais dans l’ensemble c’était plutôt stable.
La disponibilité des applications est déjà irrégulière, mais le pire, c’était les cas où fly deploy échouait sans raison. Parfois, une couche restait simplement bloquée puis finissait par échouer ; 1 ou 2 heures plus tard, en relançant la même commande sans aucun changement, tout fonctionnait normalement.
J’aimerais voir un service de monitoring qui déploie une application de base toutes les 5 minutes, autrement dit qui exécute périodiquement la commande
fly deploy, pour mesurer à quelle fréquence les déploiements échouent ou se bloquent. Je pense qu’environ 5 % échoueraient sans explication, ce qui devient assez pénible quand on n’a pas beaucoup de temps.D’après ces mesures, cela semble avoir duré 16 minutes.
fly.io a publié son analyse post-mortem ici : https://fly.io/infra-log/
Les analyses post-mortem récentes sont assez intéressantes et très détaillées. En 2016, un composant central de l’infrastructure d’exploitation de fly.io était un serveur TLS très sécurisé appelé consul, qui suivait l’état partagé et devait authentifier à la fois les certificats serveur et les certificats client.
Son architecture centralisée a posé des problèmes de passage à l’échelle ; en 2020, fly.io a créé corrosion pour le remplacer et a vite oublié consul, sans toutefois parvenir à le supprimer complètement.
Puis, en octobre 2024, la clé de signature de la clé racine de consul a expiré, ce qui a fait tomber toutes les connexions ; comme ils utilisent une authentification mutuelle, il était impossible de rétablir le service avant de déployer de nouveaux certificats SSL sur l’ensemble des machines. Ils y sont parvenus d’une façon ou d’une autre en 30 minutes, mais l’effet domino était déjà lancé et d’autres faiblesses de l’infrastructure sont apparues.
Un autre service interne disposait d’un jeu indépendant de clés TLS qui avait expiré depuis longtemps, mais personne ne s’en était rendu compte avant son redémarrage pendant le processus de réémission des clés consul. Les connexions TCP établies à l’époque où les certificats étaient encore valides ont été coupées par le redémarrage, révélant le problème. Pendant ce temps, l’outil de logging martelait le fournisseur réseau comme lors d’un DDoS. Les personnes qui ont réussi à sauver l’entreprise et à protéger les clients alors qu’autant de choses explosaient en même temps sont vraiment impressionnantes.
Pourtant, sur la page de recrutement [1], ils disent : « nous ne croyons pas vraiment à la dette technique ».
Vu de l’extérieur, cela se lit comme un chœur de contradictions.
[1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...
Fly.io semble être un service assez à double tranchant
https://news.ycombinator.com/item?id=41917436
https://news.ycombinator.com/item?id=35044516
https://news.ycombinator.com/item?id=34742946
https://news.ycombinator.com/item?id=34229751
Si une plateforme cloud n’arrive pas à fournir correctement de la fiabilité, je ne vois pas en quoi elle en vaut la peine. Il peut être préférable de simplement louer un serveur virtuel et d’économiser la taxe cloud
Cela dit, ce prix concerne une instance avec 256 Mo de RAM (https://fly.io/docs/about/pricing/). Malgré tout, il est tout à fait possible d’y faire tourner un projet utile. Un serveur web en Rust comme Rocket ne demande qu’environ 10 Mo de RAM, et d’après ce que j’ai trouvé, même un serveur PHP de base peut rentrer
Sans parler des incidents de déploiement, presque chaque jour quelque chose ne fonctionnait pas aléatoirement ou était en retard
Les hausses de prix, et le fait que mon supérieur ait vu plusieurs problèmes sur un projet que j’avais mis sur Fly, m’ont forcé à partir il y a quelques mois
En plus, ils ont aussi abandonné et supprimé le service de sauvegarde sqlite. Maintenant je suis retourné sur GCP et je ne m’inquiète plus d’innombrables incidents
Beaucoup de services de grandes entreprises, utilisés par des millions de personnes dans le monde, tournent dans une seule région AWS. Ça donne l’impression d’un outil qui rend possible, par défaut, une optimisation prématurée
Si l’objectif est d’optimiser pour maximiser la fiabilité, c’est aussi un choix parfaitement raisonnable. Je ne dirais pas qu’en 2024 nous faisons mieux qu’eux en UE1
À titre indicatif, beaucoup de choses peuvent mal tourner et c’est effectivement le cas, mais la forme d’incident que vous êtes le plus susceptible de voir ici, c’est une période où les déploiements ne passent pas. Cet incident était un problème de déploiement/orchestration. Il y a quelques mois, nous sommes tombés sur une mine de concurrence en Rust qui a provoqué une panne complète du routage des requêtes, mais ce genre de chose est très rare
Les pannes de déploiement et de mise à jour d’état sont aussi graves, et si vous continuez à déployer, comme nous le recommandons, sur différents groupes de Fly Machines, cela peut affecter la disponibilité, puisque c’est l’une des grandes fonctionnalités de la plateforme. Je n’essaie pas de minimiser cela
En réalité, en faisant tourner Firecracker sur ses propres serveurs bare metal, on peut faire presque la même chose que fly.io, et même moins cher
L’image publique de fly.io me semble déjà entachée au point d’être difficile à réparer. Je ne compte même plus le nombre d’excuses qu’ils ont présentées
Contrairement au titre de l’article, l’API Fly.io reste inaccessible. Cela signifie que les utilisateurs n’ont toujours pas accès aux déploiements, bases de données, etc.
Pour des mises à jour exactes, voir https://community.fly.io/t/fly-io-site-is-currently-inaccess...
D’après mon expérience personnelle avec Fly.io et Railway.com, Railway l’emporte haut la main. Le support de Railway est également excellent en comparaison
Fly.io n’a toujours pas répondu à ma demande de suppression de données envoyée par e-mail au support
Mes apps Railway sont restées en ligne jusqu’ici sans gros downtime. À ceux qui cherchent une alternative correcte, je recommande d’essayer Railway
L’idée est bonne, mais en pratique je n’aurais pas envie de l’utiliser pour quelque chose de sérieux
Je comprends que les utilisateurs finaux veulent de la fiabilité, et je sais aussi que Fly a beaucoup investi là-dedans ces deux dernières années tout en gardant une mauvaise réputation. Mais ce type d’incident n’est pas quelque chose qui existe chez un fournisseur et pas chez l’autre. Construire une infrastructure cloud n’est facile pour personne
Rien que parmi ceux que j’ai vus directement, c’est probablement le 5e ou 6e incident majeur de Fly.io. Il y en a eu beaucoup d’autres, et il y a de fortes chances que certains me soient simplement passés sous le nez
J’ai recommandé ce service à un ami, et il a subi deux pannes en deux jours
Fly.io doit vraiment se ressaisir. Pourquoi ils n’y arrivent toujours pas reste un mystère. Le produit est bon, mais pour un service d’hébergement, la stabilité doit absolument être la priorité numéro un. Tout le reste est secondaire
Le secret semble être de devenir un acteur établi sans vrai substitut. À ce moment-là, même si la fiabilité est complètement catastrophique, tout le monde ferme plus ou moins les yeux sur les échecs opérationnels
Curieusement, Turso a aussi commencé à avoir des problèmes à peu près au même moment. Le CEO a confirmé sur Discord que c’était à cause de l’incident Fly
Turso semble prévoir de proposer un jour un tier AWS
Ce n’est pas surprenant. Il y a environ un an, j’ai regardé fly.io à cause de ses prix bas, et je me demandais où ils réduisaient les coûts pour gagner de l’argent. J’ai fini par trouver la réponse dans la documentation technique : il y était clairement écrit que les instances fly sont attachées à un seul serveur physique et qu’en cas de panne de ce serveur, le failover est impossible. Je ne sais pas si ce passage figure encore dans la documentation officielle
En pratique, cela signifie que si le serveur tombe, il faut récupérer depuis les sauvegardes le dernier snapshot de l’instance concernée, le lancer sur un nouveau serveur, mettre à jour les routes réseau, puis prier pour que davantage de serveurs ne tombent pas que la capacité disponible ne le permet. Sinon, il faut attendre que le datacenter ajoute quelques serveurs dans les racks pour pouvoir restaurer
Cela explique aussi assez bien pourquoi les rapports d’incident semblent aléatoires. Certaines apps sont tombées, d’autres vont bien ; certaines reviennent en 5 minutes, d’autres prennent beaucoup plus longtemps
Pour une entreprise au budget serré, une autre option, comme un petit cluster civo, me semblerait préférable
Je ne comprends pas bien ce que devrait signifier autrement « les instances fly sont attachées à un seul serveur physique et le failover est impossible ». Je sais que la migration à chaud existe, mais même dans ce cas, une VM n’est-elle pas, au final, « attachée » à un serveur physique donné ?
Et ce n’est pas gratuit. Par exemple, sur GCP, lorsqu’une VM est migrée, on constate une dégradation temporaire des performances
Si la couche de proxy tombe, tout Fly peut encore tomber, mais ce cas est beaucoup moins fréquent
Un schéma qui revient souvent, c’est que les incidents se produisent fréquemment pendant les semaines de grands jours fériés aux États-Unis
MS 365/Teams/Exchange a aussi eu un bref problème le matin, Fly.io a connu une panne totale, puis plusieurs sites et services ont été secoués par ricochet
D’habitude, je suis opposé aux « gels des changements », mais autour des grands jours fériés, un gel des changements a du sens. Cela peut donner à toutes les équipes du temps pour récupérer, faire une pause et assurer la maintenance
Mieux vaut éviter de mettre trop de pression sur l’équipe B qui se retrouve d’astreinte à ce moment-là
On peut essayer de réduire aussi ce type de changements pendant les périodes de vacances, mais que faire s’il faut renouveler un certificat ? Appliquer un correctif de sécurité critique ? Reprovisionner un groupe de serveurs ? Si l’espace disque vient à manquer ?
Les difficultés opérationnelles ne peuvent pas être évitées uniquement par la planification, quelle que soit la période de l’année
Puis, finalement, une initiative marketing/produit spéciale apparaît, la logique de tarification spéciale nécessite du nouveau code et un nouveau widget UI, le trafic et la charge augmentent fortement, et même en plein gel, il faut la sortir immédiatement. Comme c’est lié au chiffre d’affaires, c’est important pour la direction
La plupart des équipes d’ingénierie et d’infrastructure n’étaient pas au courant, parce que l’équipe produit a poussé jusqu’au dernier moment et a travaillé avec un certain niveau de confidentialité. Au final, on peut geler de petites corrections de qualité, mais on ne parvient pas vraiment à geler les nouvelles fonctionnalités instables
C’est difficile, et malgré tout je recommande d’oublier le gel et d’avoir une exploitation raisonnable, sans surcharge, avant, pendant et après
On peut bloquer les changements « inutiles », mais la frontière devient très vite une zone grise
Les pannes à répétition du début 2023 impliquaient aussi des douleurs liées à Corrosion : https://community.fly.io/t/reliability-its-not-great/11253
Je ne connais pas très bien leurs contraintes, mais ScyllaDB prend en charge la cohérence éventuelle et est globalement assez flexible. Pour la réplication multi-leader, CouchDB est aussi une option