O padrão de incidentes da Fly.io entre setembro e outubro de 2026, verificado na própria página de status

A Fly.io não tem uma única queda manchete para apontar neste período — nada como um colapso de plataforma de vários dias. O que ela tem, visível na própria página de status pública, é uma cadência constante: 25 incidentes separados entre 2 de setembro e 22 de outubro de 2026, abrangendo regiões específicas, serviços específicos, e uma gama de severidades de “nenhuma” a “crítica”. Esse padrão, não um único evento, é a história real, e vale a pena olhar diretamente para ele em vez de através do resumo de outra pessoa.

O que mostra o próprio histórico de status da Fly.io

Tudo a seguir vem do próprio histórico de incidentes da Fly.io em status.flyio.net, lido através de sua API pública de incidentes, com os próprios horários e classificações de impacto da Fly.

Indisponibilidade da Upstash na região FRA — 23 de setembro, maior. Entre aproximadamente 12h e 13h05 UTC, clientes tiveram timeouts de conexão para bancos de dados Redis hospedados nas regiões fra ou gig, e para bancos em outros lugares cujas conexões passavam por fra ou gig. As próprias notas de resolução da Fly atribuem a causa raiz a uma janela de manutenção planejada da Upstash em que réplicas não foram drenadas corretamente antes de voltarem a operar. A Fly se comprometeu a adicionar ferramentas e verificações de segurança para atualizações depois disso.

Erros elevados ao criar apps e gerenciar secrets — 15 de outubro, menor (segundo a classificação da Fly). Entre 6h40 e 9h50 UTC, as solicitações de criação de apps e gerenciamento de secrets falharam ou expiraram — a própria atualização da Fly especifica que isso afetou o flyctl, a API de Machines, e o dashboard com erros 500 ou 503 nessas operações específicas. A Fly é explícita: apps e Machines já em execução não foram afetados; isso foi sobre criar coisas novas e mudar secrets, não sobre nada já implantado. São aproximadamente três horas e dez minutos em que uma equipe tentando rotacionar um secret ou subir um app novo durante um deploy teria encontrado falhas — menor pela escala de severidade da Fly, mas uma janela real de atrito para quem tivesse o momento errado.

Reinícios progressivos de todos os hosts da plataforma — 16-17 de outubro, maior. A partir das 16h22 UTC do dia 16 e concluído às 5h15 UTC do dia seguinte — cerca de 13 horas no total — a Fly realizou reinícios progressivos em toda a sua frota de hosts como o que sua própria atualização de incidente descreve como uma medida de mitigação para “PwnEscape (Linux Kernel CVE-2026-99999)”. Cada host ficou indisponível por 15 a 20 minutos durante seu próprio reinício, com as atualizações da Fly anotando o progresso em porcentagens (25%, 50%, 70%, 90%, 95% da frota reiniciada) à medida que o rollout avançava região por região. Machines, volumes e instâncias de clusters Postgres gerenciados dos clientes ficavam indisponíveis no host que estivesse no meio do reinício a qualquer momento dado — o que significa que os apps específicos afetados, e quando, dependiam inteiramente de em qual host eles rodavam, não de nada que o cliente tivesse feito.

Desempenho de borda degradado — 22 de outubro, classificado impacto “nenhum” pela Fly, mas real. Entre aproximadamente 18h e 18h10 UTC, várias regiões viram conexões perdidas elevadas e tempos de conexão mais longos que o normal para alcançar os apps. Dez minutos, corrigido, seguiu em frente — mas é o tipo de incidente que se manifesta como “meu app pareceu lento por alguns minutos sem razão que eu conseguisse encontrar nos meus próprios logs”, porque a causa não estava de jeito nenhum nos logs do cliente.

Além desses quatro, a mesma janela de sete semanas inclui: um incidente de capacidade na região GRU afetando criação de máquinas e builds remotos (20 de outubro), uma queda do dashboard Grafana para fly-metrics.net (16 de outubro), ingestão atrasada de logs históricos (13 de outubro), um problema de certificado para hospedagem de sprites (11-12 de outubro), uma falha de criação de sprites classificada crítica (8 de outubro), problemas de rede maiores em LHR (8 de outubro), uma queda parcial em AMS classificada crítica (3 de outubro), um problema de migração de banco de dados de estado em GRU (24 de setembro), um incidente de rede privada 6PN (24 de setembro), um problema de IPv6 em DFW (23 de setembro), uma queda de rede em AMS classificada crítica (26 de setembro), e mais. A lista completa é pública e datada na própria página de status da Fly.

Por que a Fly.io tem tantos incidentes?

Não porque a engenharia da Fly.io seja fraca — o oposto é mais próximo da verdade. A Fly opera uma rede de borda genuinamente global e multi-tenant: dezenas de regiões, uma camada de rede privada compartilhada (6PN), clusters Postgres gerenciados compartilhados, um sistema de build compartilhado, e uma frota de hosts físicos e virtuais nos quais as cargas de trabalho dos clientes são empacotadas para tornar tudo isso acessível e rápido. Essa arquitetura é o que torna possível o próprio diferencial da Fly: rodar seu app perto dos usuários em qualquer lugar, sem provisionar infraestrutura regional você mesmo. Também significa que qualquer degradação numa dessas camadas compartilhadas (um link de rede regional, a janela de manutenção de um provedor de Redis compartilhado, uma vulnerabilidade de kernel forçando um reinício de toda a frota) se manifesta como um incidente visível numa página de status pública, datado e com horário, porque é um único sistema compartilhado com muitos inquilinos olhando o mesmo painel.

Uma CVE de kernel em nível de plataforma é o exemplo mais claro: quando uma vulnerabilidade séria o suficiente para justificar remediação imediata é encontrada, a Fly precisa reiniciar cada host da frota, segundo o cronograma da Fly, porque os hosts são infraestrutura da Fly, compartilhada entre todos os seus inquilinos. Cada cliente rodando num host afetado vive esse reinício, tenha ele escolhido ou não corrigi-lo naquele momento, naquele dia, com aquela urgência.

O que isso significa honestamente, e o que não significa

A Fly.io é, segundo a maioria dos relatos independentes e seu próprio histórico de status transparente, uma plataforma geralmente confiável — o ponto de listar 25 incidentes em sete semanas não é que essa seja uma taxa de falha incomum para uma rede global multi-tenant; é genuinamente normal para uma, e reportar essa taxa de forma transparente é um ponto a favor da Fly, não contra. A maioria desses incidentes são regionais, curtos, e classificados como menores ou nulos. Nenhum chega perto da escala do incidente de segurança da Railway ou da queda de build de seis horas e meia da Vercel. O enquadramento honesto é mais restrito que “a Fly não é confiável”: é que uma rede de borda compartilhada e multi-tenant acumula incidentes que não afetam cada cliente da mesma forma que o próprio uptime de um único servidor dedicado.

Um servidor que você possui e opera tem exatamente um histórico de uptime: o dele. Ele não cai porque um provedor de Redis numa outra metrópole lidou mal com uma janela de manutenção pela qual seu tráfego passava por acaso. Ele não reinicia segundo um cronograma definido pela urgência de correção de kernel de outra empresa, para uma vulnerabilidade que pode ou não se aplicar à sua própria configuração — você escolhe quando corrigir seu próprio kernel, no seu próprio cronograma, tendo avaliado sua própria exposição. Ele não é afetado por uma restrição de capacidade numa região a três fusos horários de distância porque essa região compartilha infraestrutura com a sua.

O que se perde é exatamente o que a Fly vende: a rede anycast global, a capacidade de subir uma Machine em Tóquio e outra em Frankfurt sem possuir nenhum dos dois equipamentos, e o trabalho operacional de rodar essa presença você mesmo se quisesse a mesma dispersão geográfica. Um único servidor próprio tem um local, um teto de capacidade, e uma única pessoa (você) responsável por corrigir seu kernel no seu próprio cronograma — o que é liberdade real, e também uma obrigação real que uma rede de borda gerenciada tira das suas costas. Nenhum modelo é estritamente melhor; são respostas diferentes a quanto dessa superfície operacional você quer possuir versus alugar, o mesmo trade-off que percorre toda essa categoria.

O que isso significa para você

• Se seu app é genuinamente sensível à latência em múltiplas regiões globais, uma rede de borda multi-tenant como a da Fly está fazendo um trabalho de infraestrutura real e difícil que seria caro replicar em servidores próprios — é uma razão legítima para aceitar risco de infraestrutura compartilhada em troca disso.
• Se seu app atende um único público a partir de uma ou duas regiões, o histórico de uptime independente de um servidor dedicado pode ser o melhor negócio — você não paga (em risco nem em dinheiro) por um alcance global que não precisa.
• Leia o histórico de status público próprio de uma plataforma antes de se comprometer com ela, especificamente pelo padrão (frequência, duração típica, quais serviços) em vez de um único incidente — uma página de status transparente e atualizada com frequência é em si um sinal que vale a pena levar a sério, em qualquer sentido.
• Saiba qual camada realmente falhou quando algo dá errado — “meu app estava lento” diagnosticado como um soluço regional de desempenho de borda que você não consegue corrigir sozinho é um problema diferente de “o disco do meu próprio servidor estava cheio”, que você consegue corrigir.

Veja a comparação completa: Railyard contra Fly.io, e o passo a passo completo de migração: Migrar da Fly.io.

Perguntas frequentes

A Fly.io está fora do ar agora? Este texto cobre um padrão histórico de setembro e outubro de 2026, não o status em tempo real. Confira diretamente a própria página de status da Fly.io para incidentes atuais.

Por que a Fly.io tem tantos incidentes na página de status? A Fly opera uma rede de borda global e multi-tenant — infraestrutura regional compartilhada, bancos de dados gerenciados compartilhados, e uma frota de hosts compartilhada. Qualquer degradação numa dessas camadas compartilhadas (um problema de rede regional, a janela de manutenção de um provedor de banco de dados, um patch de kernel em nível de frota) se manifesta como um incidente datado numa página de status que qualquer inquilino pode ver, o que é função de operar infraestrutura compartilhada de forma transparente, não necessariamente sinal de engenharia pior.

O que foi a queda do Redis da Fly.io em setembro de 2026? Em 23 de setembro de 2026, a página de status da Fly reportou indisponibilidade do Redis Upstash na região FRA de aproximadamente 12h às 13h05 UTC, causada por réplicas que não drenaram corretamente durante uma atualização de manutenção planejada. Afetou bancos de dados hospedados em ou roteados pelas regiões fra/gig.

Hospedar no seu próprio servidor evita esse tipo de incidente? Isso remove a exposição às camadas compartilhadas específicas da Fly — sua rede regional, seu parceiro de Redis gerenciado, seu cronograma de correção de hosts — em troca de abrir mão da rede de borda global multirregional da Fly, que seria cara de replicar você mesmo. Um único servidor próprio tem seu próprio histórico de uptime independente, para o bem e para o mal.

Fontes

• Fly.io Status — histórico de incidentes — página de status própria da Fly.io
• API de incidentes do Fly.io Status — dados públicos próprios de incidentes da Fly.io para todos os incidentes citados acima, com horários exatos e classificações de impacto