Resolución completada de la incidencia de Fly.io
(status.flyio.net)- La página de estado de Fly.io muestra actualmente All Systems Operational, y los componentes principales como ejecución de apps, dashboard, Machines API y disponibilidad regional están operativos
- El incidente de Elevated API Errors del 1 de jul de 2026 se resolvió a las 07:50 UTC tras corregir errores en la GraphQL API y problemas en el procesamiento de tareas en segundo plano
- Delayed Metrics del 30 de jun provocó métricas retrasadas o faltantes en el dashboard de fly-metrics.net para algunos clientes, y se normalizó tras procesar el backlog y ampliar capacidad
- Esta página de estado es para actualizaciones de incidentes globales, por lo que no incluye fallas de hardware de impacto limitado ni eventos aislados de infraestructura
- El impacto por app debe revisarse en la personalized status page del dashboard de Fly Organization, y se indica consultar el Infra Log para incidentes internos y actividad
Estado actual del servicio
- La página de estado de Fly.io se encuentra actualmente en estado All Systems Operational
- Los principales elementos marcados como operativos son 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 y Managed Postgres
- El estado regional también aparece como operativo, y las regiones incluidas son AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD y YYZ
Alcance de la página de estado
- Esta página es para actualizaciones de global incidents
- No incluye actualizaciones sobre fallas rutinarias de hardware de impacto limitado ni eventos aislados de infraestructura
- La vista personalizada de todos los eventos que pueden afectar a una app debe revisarse en la personalized status page del dashboard de Fly Organization
- Se indica consultar el Infra Log para incidentes internos y otras actividades
1 de jul de 2026: Elevated API Errors
- Elevated API Errors fue marcado como Resolved el 1 de jul a las 07:50 UTC
- A las 06:14 UTC comenzó la investigación de elevated errors en la GraphQL API y en el procesamiento de tareas en segundo plano
- A las 06:27 UTC se identificó la causa y comenzó el trabajo de corrección
- A las 07:05 UTC se aplicó la corrección y dejaron de observarse elevated API errors
- Algunas tareas del dashboard podían seguir retrasadas mientras el procesamiento en segundo plano se ponía al día
- A las 07:26 UTC las tareas en segundo plano ya se habían puesto al día, y se continuó el monitoreo con la API completamente operativa
30 de jun de 2026: Delayed Metrics y egress IP en SIN/NRT
- Delayed Metrics se resolvió el 30 de jun a las 22:19 UTC
- Hubo un problema con las métricas para clientes en el dashboard de fly-metrics.net, por lo que los usuarios podían ver métricas retrasadas o faltantes
- Problemas en varios hosts retrasaron la recolección de métricas, y se trató como causa una resource contention en algunos metrics ingestion hosts
- Para procesar el backlog se aumentó el throughput del metrics cluster, y se realizó un rebalanceo del ingestion traffic junto con capacidad de procesamiento adicional
- El 30 de jun a las 19:58 UTC casi todas las métricas ya se habían puesto al día, aunque quedaban unas pocas de
sinysyd - Egress IP issues in SIN and NRT se resolvió el 30 de jun a las 14:03 UTC
- Algunas Machines que usan egress IP en SIN y NRT podían perder conectividad temporalmente o sufrir degradación de rendimiento
26~25 de jun de 2026: incidentes de red, despliegue y control plane
- IPv6 Connectivity Issues in EWR se resolvió el 26 de jun a las 23:48 UTC
- Se presentó un problema de conectividad de red IPv6 del upstream provider en EWR
- Las apps con Machines en hosts afectados podían verse impactadas al conectarse a ciertos destinos IPv6
- Network maintenance in YYZ fue un mantenimiento programado realizado el 26 de jun entre 08:00 y 09:00 UTC, y quedó completado
- Dentro de la ventana de mantenimiento se esperaba una pérdida de conectividad de hasta 15 minutos
- Deploys defaulting to Fly-hosted Builders se resolvió el 25 de jun a las 15:38 UTC
- Mientras se investigaba una demora en el aprovisionamiento de builders respaldados por Depot, la estrategia predeterminada de
fly deploycambió a Fly-hosted builders - Los usuarios podían forzar despliegues basados en Depot con
fly deploy --depot=true, y posteriormente también podían usar despliegues basados en Fly builder confly deploy --depot=false
- Mientras se investigaba una demora en el aprovisionamiento de builders respaldados por Depot, la estrategia predeterminada de
- Elevated control plane latency se resolvió el 25 de jun a las 15:18 UTC
- Se produjo latencia y saturación del control plane que afectó a las regiones BOM y NRT
- Las apps con Machines en esas regiones podían experimentar mayores tiempos de respuesta y posibles 502 errors
24~17 de jun de 2026: red en Norteamérica y SIN/NRT, y búsqueda de logs
- Degraded networking in North America se resolvió el 24 de jun a las 06:57 UTC
- Se investigó una degradación del rendimiento de red entre sitios de Norteamérica causada por un incidente upstream
- Algunas Machines podían experimentar pérdida de paquetes y mayor latencia en rutas específicas
- Seguía existiendo impacto en parte del tráfico de 6PN Private Networking hacia y desde la región LAX
- Network issues in SIN, NRT se resolvió el 22 de jun a las 21:56 UTC
- El upstream provider tuvo problemas de red en las regiones SIN y NRT, y las apps en esas regiones podían quedar inaccesibles o sufrir alta pérdida de paquetes
- SIN, NRT network issues se resolvió el 22 de jun a las 19:48 UTC
- Inicialmente se investigó como un problema de red upstream en la región SIN, y después se confirmó que las apps de la región NRT también podían tener problemas para llegar a ciertos destinos
- Log search unavailable se resolvió el 19 de jun a las 21:53 UTC
- Afectó los paneles de búsqueda de logs de Fly Metrics y los historical application logs devueltos inicialmente por el comando
fly logs - El streaming de
fly logs, la página Live Logs del dashboard y los servicios Fly Log Shipper funcionaron con normalidad - Tras la corrección se hizo backfill de los historical logs y la mayoría de los queued historical logs pasaron a poder buscarse
- Afectó los paneles de búsqueda de logs de Fly Metrics y los historical application logs devueltos inicialmente por el comando
- Network Issues in SIN se resolvió el 17 de jun a las 04:55 UTC
- Hubo un problema de conectividad de red en la región SIN y las apps alojadas podían quedar no disponibles
- Algunas Machines quedaron inaccesibles, y algunos clusters de Managed Postgres podían fallar en fail-over o update
1 comentarios
Opiniones en Hacker News
Mi sitio web alojado en fly.io estuvo caído durante 5 minutos hace unas 6 horas y se recuperó de inmediato; desde entonces sigue funcionando con normalidad.
El servicio gratuito de monitoreo revisa cada 5 minutos, así que puede que haya pasado por alto tiempos de caída más cortos, pero en general ha sido bastante estable.
El tiempo de actividad de la aplicación también es inestable, pero lo peor fueron los casos en que fly deploy fallaba sin motivo. A veces una capa simplemente se quedaba detenida y al final fallaba; 1 o 2 horas después, al ejecutar de nuevo el mismo comando sin ningún cambio, funcionaba correctamente.
Me gustaría ver un servicio de monitoreo que despliegue una app básica cada 5 minutos, es decir, que ejecute periódicamente el comando
fly deploy, para ver con qué frecuencia los despliegues fallan o se quedan colgados. Calculó que alrededor de un 5% falla sin explicación, y si no tienes mucho tiempo, es bastante molesto.Según ese sitio, parece que duró 16 minutos.
fly.io publicó aquí el análisis post mortem: https://fly.io/infra-log/
El análisis post mortem reciente es bastante interesante y tiene muchos detalles. En 2016, un componente clave de la infraestructura operativa de fly.io era un servidor TLS de alta seguridad llamado consul, que debía rastrear estado compartido y autenticar tanto certificados de servidor como certificados de cliente.
Al ser una arquitectura centralizada, aparecieron problemas de escalabilidad, y en 2020 fly.io creó corrosion para reemplazarlo y rápidamente se olvidó de consul, aunque no logró eliminarlo por completo.
Luego, en octubre de 2024, expiró la clave de firma raíz de consul, se cayeron todas las conexiones y, como usaban autenticación mutua, no pudieron recuperarse hasta distribuir nuevos certificados SSL en todos los equipos. De alguna manera lo lograron en 30 minutos, pero el dominó ya había empezado y también quedaron expuestas otras debilidades de la infraestructura.
Otro servicio interno tenía desde hacía tiempo vencido un conjunto independiente de claves TLS, pero no lo supieron hasta que lo reiniciaron durante el proceso de reemisión de claves de consul. Al reiniciarse, se cortaron las conexiones TCP que se habían establecido cuando los certificados aún eran válidos, y así quedó al descubierto. Mientras tanto, una herramienta de logging estaba golpeando al proveedor de red como si fuera un DDoS. La gente que mantuvo viva a la empresa y además protegió a los clientes cuando explotaron tantas cosas a la vez hizo un trabajo realmente impresionante.
Pero en la página de empleos [1] dicen: “no creemos mucho en la deuda técnica”.
Desde afuera, se lee como un coro de contradicciones.
[1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...
Fly.io parece ser un servicio bastante ambiguo
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 una plataforma cloud no puede ofrecer confiabilidad como corresponde, creo que no vale la pena. Puede convenir más alquilar simplemente un servidor virtual y ahorrarse el impuesto cloud
Eso sí, ese precio es para una instancia con 256 MB de RAM (https://fly.io/docs/about/pricing/). Aun así, es perfectamente posible correr proyectos significativos ahí. Un servidor web basado en Rust como Rocket requiere apenas unos 10 MB de RAM y, por lo que encontré, incluso un servidor PHP básico también entra
Además de fallas de despliegue, casi todos los días algo dejaba de funcionar al azar o se demoraba
Entre el aumento de precios y que mi jefe vio problemas varias veces en un proyecto que tenía en Fly, hace unos meses no me quedó otra que irme
Además, descontinuaron y eliminaron el servicio de backups de sqlite. Ahora volví a GCP y ya no me preocupo por un montón de incidentes
Hay muchos servicios de grandes empresas usados por millones de personas en todo el mundo que operan desde una sola región de AWS. Se siente como algo que habilita optimización prematura desde los valores por defecto
Si optimizas con el objetivo de maximizar la confiabilidad, esa también es una decisión totalmente razonable. No voy a decir que en 2024 seamos mejores en UE1
Como referencia, muchas cosas pueden salir mal y de hecho salen mal, pero el tipo de incidente que más probablemente verás aquí es un período en el que no se puede desplegar. Este incidente fue una falla de despliegue/orquestación. Hace unos meses pisamos una mina de concurrencia en Rust y hubo una falla total del ruteo de requests, pero eso es muy raro
Las fallas de despliegue y de actualización de estado también son graves y, si sigues desplegando en distintos grupos de Fly Machines como recomendamos, pueden afectar la disponibilidad, ya que es una de las grandes funciones de la plataforma. No intento minimizarlo
De hecho, si corres Firecracker en tus propios servidores bare metal, puedes hacer casi lo mismo que fly.io y hasta más barato
La percepción pública sobre fly.io parece ya manchada al punto de ser difícil de recuperar. Ya ni puedo contar cuántas veces se disculparon
A diferencia del título del post, la API de Fly.io sigue inaccesible. Eso significa que los usuarios todavía no pueden acceder a despliegues, bases de datos, etc.
Para actualizaciones precisas, ver https://community.fly.io/t/fly-io-site-is-currently-inaccess...
Por mi experiencia personal usando tanto Fly.io como Railway.com, Railway gana por goleada. El soporte de Railway también es excelente en comparación
Fly.io hasta ahora no respondió una consulta de eliminación de datos que envié por email a soporte
La app en Railway ha estado online hasta ahora sin downtime importante. A quien busque una alternativa decente, le recomiendo probar Railway
La idea es buena, pero en la práctica no querría usarlo para algo serio
Entiendo que los usuarios finales quieren confiabilidad, y sé que Fly invirtió bastante en esto durante los últimos 2 años y aun así tiene mala reputación. Pero este tipo de incidente no es algo que exista en un proveedor y no en otro. Construir infraestructura cloud no es fácil para nadie
Solo de los que vi directamente, este debe ser el quinto o sexto incidente importante de Fly.io. Hubo muchos otros, y seguramente algunos simplemente se me pasaron
Le recomendé este servicio a un amigo y en dos días sufrió dos incidentes
Fly.io realmente necesita ponerse las pilas. Por qué todavía no lo logró es un misterio. El producto es bueno, pero si eres un servicio de hosting, la estabilidad debe ser la prioridad absoluta. Todo lo demás es secundario
El truco parece ser convertirse en un incumbente sin buenos reemplazos. Entonces, aunque seas un desastre total en confiabilidad, todos pasan por alto más o menos tus fallas operativas
Curiosamente, Turso también empezó a tener problemas casi al mismo tiempo. El CEO confirmó en Discord que era por la caída de Fly
Parece que Turso planea ofrecer algún día un tier en AWS
No me sorprende. Hace alrededor de un año revisé fly.io por sus precios bajos, y me preguntaba en dónde recortaban costos para ganar dinero. Al final encontré la respuesta en la documentación técnica: decía claramente que las instancias de fly quedan fijadas a un único servidor físico y que, si ese servidor muere, no es posible hacer failover. No sé si esa parte todavía está en la documentación oficial
En la práctica, eso significa que si un servidor se cae, tienen que cargar desde el backup el último snapshot de esa instancia en un servidor nuevo, actualizar las rutas de red y rezar para que no se caigan más servidores de los que alcanza a cubrir la capacidad disponible. Si no, hay que esperar la recuperación hasta que el datacenter conecte algunos servidores más al rack
Eso también explica bastante bien que los reportes de fallas parezcan aleatorios. Algunas apps se cayeron y otras siguieron bien; algunas volvieron en 5 minutos y otras tardaron mucho más
Si es un negocio con presupuesto ajustado, creo que otras opciones, como un clúster pequeño de Civo, podrían ser mejores
La parte de que “las instancias de fly quedan fijadas a un único servidor físico y no pueden hacer failover” no entiendo bien cómo se supone que debería ser de otra manera. Sé que existe la migración en vivo, pero incluso en ese caso, ¿la VM no termina estando “fijada” a algún servidor físico?
Y no es gratis. Por ejemplo, en GCP, cuando se migra una VM hay una degradación temporal de rendimiento que se puede percibir
Si falla la capa de proxy, Fly completo todavía puede caerse, pero esos casos son mucho menos comunes
Un patrón que se ve repetidamente es que suelen ocurrir incidentes en semanas con feriados importantes en EE. UU.
MS 365/Teams/Exchange también tuvo un problema breve en la mañana, Fly.io tuvo una caída total, y luego varios sitios y servicios se vieron afectados por eso
Normalmente me opongo a los “congelamientos de cambios”, pero creo que alrededor de feriados importantes un congelamiento de cambios tiene sentido. Puede dar a todos los equipos tiempo para recargar energías, parar y hacer mantenimiento
Es mejor no poner demasiada presión sobre el equipo B al que justo le tocó estar de guardia
En temporada de vacaciones uno puede intentar reducir también esos cambios, pero ¿qué pasa si hay que renovar certificados? ¿Aplicar un parche de seguridad importante? ¿Reaprovisionar un conjunto de servidores? ¿Si se queda sin espacio el disco duro?
En cualquier época del año, los problemas operativos difíciles no se pueden evitar solo con planificación
Luego aparece una iniciativa especial de marketing/producto, la lógica de precios especial necesita código nuevo y un widget nuevo de UI, el tráfico y la carga se disparan, y aunque hay congelamiento, tiene que salir ahora mismo. Como está relacionado con ingresos, para la dirección es importante
La mayoría de los equipos de ingeniería e infraestructura no estaban enterados porque el equipo de producto lo empujó hasta el último minuto y lo manejó con cierto nivel de secreto. Al final, puedes congelar pequeños cambios de calidad, pero no logras congelar bien funciones nuevas inestables
Es difícil, y aun así recomiendo olvidarse del congelamiento y operar de forma razonable, sin sobrecargarse antes, durante ni después
Puedes bloquear cambios “innecesarios”, pero esa frontera se vuelve zona gris muy rápido
En la serie de incidentes de principios de 2023 también hubo dolores relacionados con Corrosion: https://community.fly.io/t/reliability-its-not-great/11253
No conozco muy bien las restricciones, pero ScyllaDB soporta consistencia eventual y en general es bastante flexible. Para replicación multi-líder, CouchDB también es una opción