El patrón de incidentes de Fly.io entre septiembre y octubre de 2026, verificado en su propia página de estado

Fly.io no tiene una sola caída de titular que señalar en este periodo, nada como un colapso de plataforma de varios días. Lo que sí tiene, visible en su propia página de estado pública, es una cadencia constante: 25 incidentes separados entre el 2 de septiembre y el 22 de octubre de 2026, abarcando regiones específicas, servicios específicos, y un rango de severidades de “ninguna” a “crítica”. Ese patrón, no un solo evento, es la historia real, y vale la pena mirarlo directamente en vez de a través del resumen de alguien más.

Lo que muestra el propio historial de estado de Fly.io

Todo lo siguiente viene del propio historial de incidentes de Fly.io en status.flyio.net, leído a través de su API pública de incidentes, con las propias marcas de tiempo y clasificaciones de impacto de Fly.

Indisponibilidad de Upstash en la región FRA — 23 de septiembre, mayor. Entre las 12:00 y las 13:05 UTC aproximadamente, clientes tuvieron tiempos de espera de conexión a bases de datos Redis alojadas en las regiones fra o gig, y a bases en otros lugares cuyas conexiones se enrutaban por fra o gig. Las propias notas de resolución de Fly atribuyen la causa raíz a una ventana de mantenimiento planeada de Upstash donde las réplicas no drenaron correctamente antes de volver a servicio. Fly se comprometió a agregar herramientas y verificaciones de seguridad para actualizaciones después de esto.

Errores elevados al crear apps y gestionar secretos — 15 de octubre, menor (según la clasificación de Fly). Entre las 06:40 y las 09:50 UTC, las solicitudes de creación de apps y gestión de secretos fallaron o se agotaron: la propia actualización de Fly especifica que afectó a flyctl, la API de Machines, y el dashboard con errores 500 o 503 en estas operaciones específicas. Fly es explícita en que las apps y Machines ya en ejecución no se vieron afectadas; esto fue sobre crear cosas nuevas y cambiar secretos, no sobre algo ya desplegado. Son aproximadamente tres horas y diez minutos donde un equipo tratando de rotar un secreto o levantar una app nueva durante un despliegue habría encontrado fallas: menor según la escala de severidad de Fly, pero una ventana real de fricción para quien tuviera el momento equivocado.

Reinicios progresivos de todos los hosts de la plataforma — 16-17 de octubre, mayor. Desde las 16:22 UTC del día 16 hasta completarse a las 05:15 UTC del día siguiente, unas 13 horas en total, Fly realizó reinicios progresivos en toda su flota de hosts como lo que su propia actualización de incidente describe como una medida de mitigación para “PwnEscape (Linux Kernel CVE-2026-99999)”. Cada host estuvo indisponible entre 15 y 20 minutos durante su propio reinicio, con las actualizaciones de Fly anotando el progreso en porcentajes (25%, 50%, 70%, 90%, 95% de la flota reiniciada) a medida que el despliegue avanzaba región por región. Las Machines, volúmenes e instancias de clústeres Postgres administrados de los clientes estaban indisponibles en el host que estuviera a mitad de reinicio en cualquier momento dado, lo que significa que las apps específicas afectadas, y cuándo, dependían enteramente de en qué host corrían, no de nada que el cliente hubiera hecho.

Rendimiento de borde degradado — 22 de octubre, clasificado impacto “ninguno” por Fly, pero real. Entre aproximadamente las 18:00 y las 18:10 UTC, varias regiones vieron conexiones perdidas elevadas y tiempos de conexión más largos de lo usual para llegar a las apps. Diez minutos, resuelto, seguimos adelante, pero es el tipo de incidente que se manifiesta como “mi app se sintió lenta por unos minutos sin razón que pudiera encontrar en mis propios logs”, porque la causa no estaba para nada en los logs del cliente.

Más allá de estos cuatro, la misma ventana de siete semanas incluye: un incidente de capacidad en la región GRU que afectó la creación de máquinas y builds remotos (20 de octubre), una caída del dashboard de Grafana para fly-metrics.net (16 de octubre), ingestión retrasada de logs históricos (13 de octubre), un problema de certificado para el hosting de sprites (11-12 de octubre), una falla de creación de sprites clasificada crítica (8 de octubre), problemas de red mayores en LHR (8 de octubre), una caída parcial en AMS clasificada crítica (3 de octubre), un problema de migración de base de datos de estado en GRU (24 de septiembre), un incidente de redes privadas 6PN (24 de septiembre), un problema de IPv6 en DFW (23 de septiembre), una caída de red en AMS clasificada crítica (26 de septiembre), y más. La lista completa es pública y está fechada en la propia página de estado de Fly.

¿Por qué Fly.io tiene tantos incidentes?

No porque la ingeniería de Fly.io sea débil; es más bien lo contrario. Fly opera una red de borde genuinamente global y multiinquilino: docenas de regiones, una capa de redes privadas compartida (6PN), clústeres Postgres administrados compartidos, un sistema de build compartido, y una flota de hosts físicos y virtuales sobre los que se empaquetan las cargas de trabajo de los clientes para que todo resulte asequible y rápido. Esa arquitectura es lo que hace posible el propio argumento de venta de Fly: correr tu app cerca de los usuarios en cualquier lugar, sin aprovisionar infraestructura regional tú mismo. También significa que cualquier degradación en una de esas capas compartidas (un enlace de red regional, la ventana de mantenimiento de un proveedor de Redis compartido, una vulnerabilidad de kernel que obliga a reiniciar toda la flota) se manifiesta como un incidente visible en una página de estado pública, fechado y con marca de tiempo, porque es un solo sistema compartido con muchos inquilinos mirando el mismo tablero.

Una CVE de kernel a nivel de plataforma es el ejemplo más claro: cuando se encuentra una vulnerabilidad lo bastante seria como para justificar remediación inmediata, Fly tiene que reiniciar cada host de la flota, según el calendario de Fly, porque los hosts son infraestructura de Fly, compartida entre todos sus inquilinos. Cada cliente que corre en un host afectado vive ese reinicio, haya elegido o no parcharlo en ese momento, ese día, con esa urgencia.

Lo que esto significa honestamente, y lo que no

Fly.io es, según la mayoría de los relatos independientes y su propio historial de estado transparente, una plataforma generalmente confiable; el punto de listar 25 incidentes en siete semanas no es que esta sea una tasa de falla inusual para una red global multiinquilino, es genuinamente normal para una, y reportar esa tasa de forma transparente es un punto a favor de Fly, no en contra. La mayoría de estos incidentes son regionales, cortos, y clasificados como menores o nulos. Ninguno se acerca a la escala del incidente de seguridad de Railway o la caída de build de seis horas y media de Vercel. El encuadre honesto es más estrecho que “Fly no es confiable”: es que una red de borde compartida y multiinquilino acumula incidentes que no afectan a cada cliente de la misma manera que el propio tiempo de actividad de un solo servidor dedicado.

Un servidor que tú posees y operas tiene exactamente un historial de tiempo de actividad: el suyo. No se cae porque un proveedor de Redis en otra metrópoli manejó mal una ventana de mantenimiento por la que tu tráfico pasaba de casualidad. No se reinicia según un calendario fijado por la urgencia de parcheo de kernel de alguien más, para una vulnerabilidad que puede o no aplicar a tu propia configuración: tú eliges cuándo parchear tu propio kernel, en tu propio calendario, habiendo evaluado tu propia exposición. No se ve afectado por una restricción de capacidad en una región a tres husos horarios de distancia porque esa región comparte infraestructura con la tuya.

Lo que se pierde es exactamente lo que Fly vende: la red anycast global, la capacidad de levantar una Machine en Tokio y otra en Fráncfort sin poseer ninguno de los dos equipos, y el trabajo operativo de correr esa huella tú mismo si quisieras la misma dispersión geográfica. Un solo servidor propio tiene una ubicación, un techo de capacidad, y una sola persona (tú) responsable de parchear su kernel en tu propio calendario, lo cual es libertad real, y también una obligación real que una red de borde administrada te quita de encima. Ningún modelo es estrictamente mejor; son respuestas distintas a cuánta de esa superficie operativa quieres poseer frente a rentar, el mismo compromiso que recorre toda esta categoría.

Qué significa esto para ti

Si tu app es genuinamente sensible a la latencia en múltiples regiones globales, una red de borde multiinquilino como la de Fly está haciendo un trabajo de infraestructura real y difícil que sería costoso replicar en servidores propios: es una razón legítima para aceptar riesgo de infraestructura compartida a cambio.
Si tu app sirve a una sola audiencia desde una o dos regiones, el historial de tiempo de actividad independiente de un servidor dedicado puede ser el mejor trato: no pagas (en riesgo ni en dinero) por un alcance global que no necesitas.
Lee el historial de estado público propio de una plataforma antes de comprometerte con ella, específicamente por el patrón (frecuencia, duración típica, qué servicios) más que por un solo incidente: una página de estado transparente y actualizada con frecuencia es en sí misma una señal que vale la pena tomar en serio, en cualquier sentido.
Sabe qué capa falló realmente cuando algo sale mal — “mi app estaba lenta” diagnosticado como un bache regional de rendimiento de borde que no puedes arreglar tú mismo es un problema distinto de “el disco de mi propio servidor estaba lleno”, que sí puedes arreglar.

Mira la comparación completa: Railyard contra Fly.io, y el recorrido de migración completo: Migrar desde Fly.io.

Preguntas frecuentes

¿Fly.io está caído ahora mismo? Este artículo cubre un patrón histórico de septiembre y octubre de 2026, no el estado en tiempo real. Revisa directamente la propia página de estado de Fly.io para incidentes actuales.

¿Por qué Fly.io tiene tantos incidentes en su página de estado? Fly opera una red de borde global y multiinquilino: infraestructura regional compartida, bases de datos administradas compartidas, y una flota de hosts compartida. Cualquier degradación en una de esas capas compartidas (un problema de red regional, la ventana de mantenimiento de un proveedor de base de datos, un parche de kernel a nivel de flota) se manifiesta como un incidente fechado en una página de estado que cualquier inquilino puede ver, lo cual es función de operar infraestructura compartida de forma transparente, no necesariamente señal de peor ingeniería.

¿Qué fue la caída de Redis de Fly.io en septiembre de 2026? El 23 de septiembre de 2026, la página de estado de Fly reportó indisponibilidad de Redis Upstash en la región FRA de 12:00 a 13:05 UTC aproximadamente, causada por réplicas que no drenaron correctamente durante una actualización de mantenimiento planeada. Afectó bases de datos alojadas en o enrutadas por las regiones fra/gig.

¿Alojar en tu propio servidor evita este tipo de incidentes? Elimina la exposición a las capas compartidas específicas de Fly: su red regional, su socio de Redis administrado, su calendario de parcheo de hosts, a cambio de renunciar a la red de borde global multirregión de Fly, que sería costosa de replicar tú mismo. Un solo servidor propio tiene su propio historial de tiempo de actividad independiente, para bien y para mal.

Fuentes

Fly.io Status — historial de incidentes — página de estado propia de Fly.io
API de incidentes de Fly.io Status — datos públicos propios de incidentes de Fly.io para todos los incidentes citados arriba, con marcas de tiempo exactas y clasificaciones de impacto