Falha no Fly.io resolvida
(status.flyio.net)- A página de status do Fly.io está atualmente em All Systems Operational, com os principais componentes em operação, como execução de apps, dashboard, Machines API e disponibilidade regional
- O incidente Elevated API Errors de 1 de jul. de 2026 foi resolvido às 07:50 UTC após a correção de erros na GraphQL API e no processamento de tarefas em segundo plano
- O incidente Delayed Metrics de 30 de jun. gerou métricas atrasadas ou ausentes no dashboard fly-metrics.net para alguns clientes, e voltou ao normal após o processamento do backlog e a ampliação de capacidade
- Esta página de status é destinada a atualizações de incidentes globais, por isso não inclui falhas de hardware de impacto limitado nem eventos isolados de infraestrutura
- Os impactos por app devem ser verificados na personalized status page do dashboard da Fly Organization, e incidentes internos e atividades devem ser consultados no Infra Log
Status atual do serviço
- A página de status do Fly.io está atualmente em All Systems Operational
- Os principais itens marcados como operacionais são 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 e Managed Postgres
- O status regional também aparece como operacional, abrangendo AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD e YYZ
Escopo da página de status
- Esta página serve para atualizações de global incidents
- Não inclui atualizações sobre falhas rotineiras de hardware com impacto limitado nem eventos isolados de infraestrutura
- Para uma visão personalizada de todos os eventos que podem afetar um app, é preciso consultar a personalized status page no dashboard da Fly Organization
- Incidentes internos e outras atividades devem ser consultados no Infra Log
1 de jul. de 2026: Elevated API Errors
- Elevated API Errors foi marcado como Resolved em 1 de jul., às 07:50 UTC
- Às 06:14 UTC, começou a investigação de elevated errors na GraphQL API e no processamento de tarefas em segundo plano
- Às 06:27 UTC, a causa foi identificada e a correção entrou em andamento
- Às 07:05 UTC, a correção foi aplicada e os elevated API errors deixaram de aparecer
- Algumas tarefas do dashboard puderam sofrer atraso enquanto o processamento em segundo plano alcançava o backlog
- Às 07:26 UTC, as tarefas em segundo plano já haviam alcançado o ritmo normal, e a API seguiu em monitoramento totalmente operacional
30 de jun. de 2026: Delayed Metrics e egress IP em SIN/NRT
- Delayed Metrics foi resolvido em 30 de jun., às 22:19 UTC
- Houve um problema nas métricas voltadas ao cliente no dashboard fly-metrics.net, e os usuários puderam ver métricas atrasadas ou ausentes
- Problemas em vários hosts atrasaram a coleta de métricas, e resource contention em alguns metrics ingestion hosts foi tratado como causa
- A vazão do metrics cluster foi aumentada para processar o backlog, com rebalanceamento do ingestion traffic e adição de capacidade de processamento
- Em 30 de jun., às 19:58 UTC, quase todas as métricas já haviam alcançado o normal, mas ainda restavam poucas métricas em
sinesyd - Egress IP issues in SIN and NRT foi resolvido em 30 de jun., às 14:03 UTC
- Algumas Machines que usam egress IP em SIN e NRT puderam perder conectividade temporariamente ou sofrer degradação de desempenho
26~25 de jun. de 2026: incidentes de rede, deploy e control plane
- IPv6 Connectivity Issues in EWR foi resolvido em 26 de jun., às 23:48 UTC
- Houve um problema de conectividade de rede IPv6 do upstream provider em EWR
- Apps com Machines nos hosts afetados puderam ser impactados na conexão com determinados destinos IPv6
- Network maintenance in YYZ foi uma manutenção programada realizada em 26 de jun., das 08:00 às 09:00 UTC, e concluída
- Dentro da janela de manutenção, era esperada uma perda de conexão de até 15 minutos
- Deploys defaulting to Fly-hosted Builders foi resolvido em 25 de jun., às 15:38 UTC
- Durante a investigação de atrasos no provisionamento de Depot backed builders, a estratégia padrão do
fly deployfoi alterada para Fly-hosted builders - Os usuários podiam forçar deploys baseados em Depot com
fly deploy --depot=true, e depois também era possível usar deploys com Fly builder viafly deploy --depot=false
- Durante a investigação de atrasos no provisionamento de Depot backed builders, a estratégia padrão do
- Elevated control plane latency foi resolvido em 25 de jun., às 15:18 UTC
- Houve latência elevada e saturação no control plane afetando as regiões BOM e NRT
- Apps com Machines nessas regiões puderam sofrer tempos de resposta maiores e possíveis 502 errors
24~17 de jun. de 2026: rede na América do Norte e em SIN/NRT, e busca de logs
- Degraded networking in North America foi resolvido em 24 de jun., às 06:57 UTC
- A degradação de desempenho da rede entre sites na América do Norte foi investigada devido a um incidente upstream
- Algumas Machines puderam apresentar perda de pacotes e latência maior em rotas específicas
- Ainda restava impacto em parte do tráfego de 6PN Private Networking de/para a região LAX
- Network issues in SIN, NRT foi resolvido em 22 de jun., às 21:56 UTC
- O upstream provider enfrentou problemas de rede nas regiões SIN e NRT, e os apps dessas regiões puderam ficar inacessíveis ou apresentar alta perda de pacotes
- SIN, NRT network issues foi resolvido em 22 de jun., às 19:48 UTC
- Inicialmente, o caso foi investigado como um problema de rede upstream na região SIN, e depois apps da região NRT também puderam ter dificuldade para alcançar determinados destinos
- Log search unavailable foi resolvido em 19 de jun., às 21:53 UTC
- Afetou os painéis de busca de logs do Fly Metrics e os logs históricos de aplicação retornados inicialmente pelo comando
fly logs - O streaming do
fly logs, a página Live Logs no dashboard e os serviços Fly Log Shipper seguiram funcionando normalmente - Após a correção, os historical logs passaram por backfill, e a maior parte dos logs históricos enfileirados voltou a ficar pesquisável
- Afetou os painéis de busca de logs do Fly Metrics e os logs históricos de aplicação retornados inicialmente pelo comando
- Network Issues in SIN foi resolvido em 17 de jun., às 04:55 UTC
- Houve um problema de conectividade de rede na região SIN, e apps hospedados puderam ficar indisponíveis
- Algumas Machines ficaram inacessíveis, e alguns clusters do Managed Postgres puderam falhar em fail-over ou update
1 comentários
Comentários do Hacker News
meu site hospedado na fly.io ficou fora do ar por 5 minutos há umas 6 horas, voltou logo em seguida e desde então segue normal
o serviço gratuito de monitoramento verifica a cada 5 minutos, então pode ter perdido um downtime mais curto, mas no geral foi bem estável
o uptime da aplicação também era instável, mas pior ainda eram os casos em que o fly deploy falhava sem motivo aparente. Às vezes a camada simplesmente travava e no fim falhava, mas 1 ou 2 horas depois, ao executar o mesmo comando de novo sem nenhuma mudança, tudo funcionava normalmente
queria um serviço de monitoramento que fizesse deploy de um app básico a cada 5 minutos, ou seja, executasse periodicamente o comando
fly deploypara ver com que frequência o deploy falha ou trava. Meu palpite é que algo em torno de 5% falha sem explicação, o que é irritante num nível considerável quando você não tem muito tempopor esse critério, parece ter durado 16 minutos
a fly.io publicou a análise pós-incidente aqui: https://fly.io/infra-log/
as análises pós-incidente recentes são bem interessantes e cheias de detalhes. Em 2016, um componente central da infraestrutura operacional da fly.io era o consul, um servidor TLS altamente seguro, que rastreava estado compartilhado e precisava autenticar tanto certificados de servidor quanto certificados de cliente
por ser uma estrutura centralizada, surgiram problemas de escalabilidade, e a fly.io criou em 2020 o corrosion para substituí-lo, esquecendo rapidamente o consul, mas sem conseguir removê-lo por completo
então, em outubro de 2024, a chave de assinatura da chave-raiz do consul expirou, derrubando todas as conexões, e como usavam autenticação mútua, não foi possível recuperar até distribuir novos certificados SSL para toda a frota. De algum jeito conseguiram fazer isso em 30 minutos, mas o efeito dominó já tinha começado e outras fragilidades da infraestrutura também vieram à tona
outro serviço interno tinha um conjunto independente de chaves TLS expirado havia muito tempo, mas isso só foi descoberto quando ele reiniciou durante o processo de reemissão das chaves do consul. As conexões TCP estabelecidas quando o certificado ainda era válido foram interrompidas pelo reinício, o que expôs o problema. No meio disso, a ferramenta de logging estava batendo no provedor de rede como se fosse um DDoS. As pessoas que conseguiram salvar a empresa e ainda proteger os clientes enquanto tanta coisa quebrava ao mesmo tempo foram realmente impressionantes
mas, na página de vagas [1], dizem que “não acreditamos muito em dívida técnica”
visto de fora, isso soa como um coro de contradições
[1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...
A Fly.io parece ser um serviço bem ambivalente
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
Se uma plataforma de nuvem não consegue oferecer confiabilidade de verdade, então não vejo muito valor nela. Talvez seja melhor simplesmente alugar um servidor virtual e economizar o imposto da nuvem
Só que esse preço é para uma instância com 256 MB de RAM (https://fly.io/docs/about/pricing/). Ainda assim, dá perfeitamente para rodar projetos significativos nisso. Servidores web em Rust, como Rocket, exigem só uns 10 MB de RAM, e pelo que vi até um servidor PHP básico cabe nisso
Além de falhas de deploy, quase todo dia alguma coisa falhava aleatoriamente ou ficava lenta
Acabei tendo que sair há alguns meses por causa do aumento de preço e porque meu chefe viu vários problemas em projetos que eu havia colocado na Fly
Além disso, o serviço de backup de sqlite também foi descontinuado e removido. Agora voltei para a GCP e não fico mais preocupado com tantas falhas
Há muitos grandes serviços usados por milhões de pessoas no mundo todo que operam a partir de uma única região da AWS. Parece algo que permite otimização prematura já no padrão inicial
Se o objetivo for otimizar para máxima confiabilidade, isso também é uma escolha completamente razoável. Não vou dizer que em 2024 estamos melhores em UE1
Se isso ajudar como referência, muita coisa pode dar errado e de fato dá, mas o tipo de incidente mais provável de se ver aqui é um período em que deploys não funcionam. Esta falha foi um incidente de deploy/orquestração. Há alguns meses, pisamos numa mina terrestre de concorrência em Rust e houve uma falha total no roteamento de requisições, mas isso é bem raro
Falhas de deploy e de atualização de estado também são graves, e se você continua fazendo deploy em vários grupos de Fly Machines, como recomendamos, isso pode afetar a disponibilidade, já que é um dos grandes recursos da plataforma. Não estou tentando minimizar isso
Na verdade, se você rodar Firecracker em seus próprios servidores bare metal, pode fazer quase a mesma coisa que a fly.io faz, e por menos
A percepção pública da fly.io parece já estar manchada num nível difícil de reverter. Já nem dá para contar quantas vezes eles pediram desculpas
Ao contrário do título do post, a API da Fly.io ainda continua inacessível. Isso significa que os usuários ainda não conseguem acessar deploys, bancos de dados etc.
Para uma atualização exata, veja https://community.fly.io/t/fly-io-site-is-currently-inaccess...
Pela minha experiência pessoal usando tanto Fly.io quanto Railway.com, a Railway ganha de lavada. O suporte da Railway também é excelente em comparação
A Fly.io nunca respondeu até hoje a uma solicitação de exclusão de dados que enviei por e-mail ao suporte
O app da Railway ficou online até agora sem grandes períodos de indisponibilidade. Para quem procura uma alternativa decente, eu recomendaria testar a Railway
A ideia é boa, mas na prática eu não gostaria de usar isso para algo sério
Eu entendo que o usuário final quer confiabilidade e também sei que a Fly investiu bastante nisso nos últimos 2 anos, mesmo assim continua com uma reputação ruim. Mas esse tipo de incidente não é algo que exista só em um provedor e não em outro. Construir infraestrutura de nuvem não é fácil para ninguém
Só do que eu vi pessoalmente, este provavelmente é o 5º ou 6º grande incidente da Fly.io. Houve muitos outros, e é bem possível que eu simplesmente tenha perdido alguns
Recomendei esse serviço a um amigo, e em dois dias ele passou por duas falhas
A Fly.io realmente precisa se acertar. É um mistério por que ainda não conseguiu fazer isso. O produto é bom, mas, para um serviço de hospedagem, estabilidade tem que ser prioridade absoluta. Todo o resto é secundário
O segredo parece ser virar um incumbente sem substituto claro. Aí, mesmo sendo completamente bagunçado em termos de confiabilidade, todo mundo releva mais ou menos as falhas operacionais
Curiosamente, a Turso também começou a ter problemas quase no mesmo horário. O CEO confirmou no Discord que foi por causa da falha da Fly
Aparentemente, a Turso pretende oferecer uma camada AWS em algum momento
Não é surpreendente. Cerca de um ano atrás eu dei uma olhada na fly.io por causa do preço baixo e fiquei me perguntando onde eles economizavam para ganhar dinheiro. Acabei encontrando a resposta na documentação técnica, onde estava claramente escrito que uma instância da fly fica presa a um único servidor físico e, se esse servidor morrer, não há failover possível. Não sei se essa parte ainda está na documentação oficial
Na prática, isso significa que, se o servidor cair, eles restauram o último snapshot daquela instância a partir do backup em um novo servidor, atualizam o caminho de rede e torcem para que não tenham morrido mais servidores do que a capacidade de sobra. Caso contrário, é preciso esperar a recuperação até que o datacenter coloque mais alguns servidores no rack
Isso também explica bastante por que os relatos de falha parecem aleatórios. Alguns apps caem, outros ficam normais, alguns voltam em 5 minutos e outros demoram muito mais
Se for um negócio com orçamento apertado, talvez outra opção, como um pequeno cluster da Civo, faça mais sentido
Quanto à parte de “a instância da fly fica presa a um único servidor físico e não há failover possível”, não entendo muito bem como isso deveria ser diferente. Sei que existe migração ao vivo, mas mesmo nesse caso a VM não continua, no fim das contas, “presa” a algum servidor físico?
E isso também não é de graça. Por exemplo, quando uma VM é migrada no GCP, há uma degradação temporária de desempenho perceptível
Se a camada de proxy falhar, a Fly inteira ainda pode cair, mas esse tipo de caso é bem menos comum
Um padrão que aparece repetidamente é que falhas costumam acontecer em semanas com grandes feriados nos EUA
O MS 365/Teams/Exchange também teve um problema rápido pela manhã, a Fly.io teve uma falha total, e depois vários sites e serviços oscilaram por causa disso
Em geral sou contra “congelamento de mudanças”, mas acho que faz sentido antes e depois de grandes feriados haver um congelamento de mudanças. Isso pode dar tempo para todas as equipes recarregarem as energias, fazerem uma pausa e manutenção
Melhor não colocar pressão demais no time B que, por azar, estiver de plantão
Dá para tentar reduzir esse tipo de mudança no período de férias, mas e se for preciso renovar certificados? Aplicar um patch de segurança importante? Reprovisionar um conjunto de servidores? Ficar sem espaço em disco?
Não dá para evitar desafios operacionais em qualquer época do ano só com planejamento
Aí acaba surgindo alguma ação especial de marketing/produto, a lógica especial de preços exige código novo e um novo widget de UI, o tráfego e a carga disparam, e mesmo durante o congelamento isso precisa entrar imediatamente. Como envolve receita, para a diretoria isso é importante
A maioria dos times de engenharia e infraestrutura não sabia disso porque o time de produto foi empurrando até o último minuto e tocou parte disso de forma meio sigilosa. No fim, você consegue congelar pequenas correções de alta qualidade, mas não consegue congelar direito novas funcionalidades instáveis
É complicado e, ainda assim, eu recomendaria esquecer o congelamento e apenas operar de forma sensata, sem exageros, antes, durante e depois do período
Dá para bloquear mudanças “desnecessárias”, mas esse limite vira uma zona cinzenta muito rapidamente
Nas falhas em sequência do começo de 2023 também houve sofrimento relacionado ao Corrosion: https://community.fly.io/t/reliability-its-not-great/11253
Não conheço tão bem as restrições, mas o ScyllaDB suporta consistência eventual e, no geral, é bastante flexível. Para replicação multi-líder, o CouchDB também é uma opção