Um bug de um milissegundo parou o tráfego aéreo do Reino Unido. Seis horas.
Às 10:00 de terça-feira, 8 de setembro, uma solicitação rotineira de código squawk dentro do Sistema Nacional de Espaço Aéreo (NAS) da NATS é interrompida por uma mensagem de maior prioridade enquanto está parcialmente atualizando um valor.
Às 10:00 de terça-feira, 8 de setembro, uma solicitação rotineira de código squawk dentro do Sistema Nacional de Espaço Aéreo (NAS) da NATS é interrompida por uma mensagem de maior prioridade enquanto está parcialmente atualizando um valor. A janela de exposição é de cerca de um milissegundo. A solicitação é retomada incorretamente, os dados de voo saem corrompidos e, às 19:30, mais de 2.000 voos no Reino Unido foram atrasados, cancelados ou desviados.
Leia a edição escrita (Inglês) ↗
O que este vídeo aborda
- 10:00: uma solicitação, interrompida dentro de uma janela de 1 ms
- Cronologia: 10:00 squawk → 10:02 blip → 12:45 partidas param → 13:32 link perdido
- A cura: reiniciar os dados de voo de todo o país
- Mecanismo: pausado na metade de uma gravação
- Por que um recurso de segurança parou o céu
Transcrição traduzida
Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.
10:00: uma solicitação, interrompida dentro de uma janela de 1 ms
0:00 Às dez da manhã, uma solicitação rotineira dentro do sistema de dados de voo da Grã-Bretanha é interrompida exatamente no milissegundo errado, e à noite mais de dois mil voos são atrasados, cancelados ou desviados. Isso é do relatório preliminar da Nats, o tráfego aéreo do Reino Unido serviço. Nenhum sinal de ataque, e ninguém apertou o botão errado. Apenas um defeito legado e um milissegundo muito específico. Como aconteceu, por que um milissegundo foi suficiente e quem realmente leva a culpa. Este é The Daily Diff, post-mortem.
0:31 Dez horas. Alguém pede manualmente um código squawk, o número de quatro dígitos que
Cronologia: 10:00 squawk → 10:02 blip → 12:45 partidas param → 13:32 link perdido
0:36 liga um ponto de radar ao seu plano de voo. A solicitação é válida, e o plano também. Dez e dois. O link entre o Controle de Área de Londres e o sistema central cai, depois volta sozinho após quarenta e cinco segundos. O bilhete diz recuperado, estável, sem impacto operacional. Doze e trinta e dois. O link começa a cair novamente, mais rápido a cada vez, e os controladores perdem alguma automação.
0:56 Às doze e quarenta e cinco, as partidas do Reino Unido são interrompidas. À uma e trinta e dois, o link cai e permanece inativo. A cura é um reinício controlado, e essa é a parte cara,
A cura: reiniciar os dados de voo de todo o país
1:06 porque o mesmo sistema alimenta centros de controle e aeroportos em todo o país. O bug mora no espaço aéreo de Londres. As restrições cobrem todo o Reino Unido. O reinício vai das três e quinze às quatro e dez, e o desenrolar dos planos de voo duplicados leva até as seis e cinquenta. Então, por que um milissegundo foi suficiente?
Mecanismo: pausado na metade de uma gravação
1:23 O sistema lida com tarefas por prioridade, e pausar uma tarefa pequena por uma urgente é normal. Mas esta tarefa estava na metade da atualização de um valor. A mensagem urgente chega dentro desse milissegundo, e a atualização para na metade. Quando ela é retomada, não é retomada corretamente. Os dados ruins então vazam para algumas das atualizações de voo posteriores.
Por que um recurso de segurança parou o céu
1:40 Londres tenta ler um, leva muito tempo e expira. Um tempo limite derruba o link, como projetado, para proteger ambos os sistemas. O recurso de segurança funciona perfeitamente. Esse é o problema. As próprias palavras do relatório. Se a mensagem urgente tivesse chegado um milissegundo antes ou depois, a atualização teria sido concluída normalmente. No Hacker News, um programador chama um milissegundo de uma eternidade absoluta,
2:02 garantido para acontecer até terça-feira desta semana. Era uma terça-feira.
git blame — código legado 50 · plano de reinício 30 · o alarme das 10:02 15 · 1 ms 5
2:05 git blame. O código legado, cinquenta por cento, para uma atualização que pode ser pausada na metade e volta errada. O plano de reinício, trinta, porque um registro ruim em Londres significa reiniciar o os dados de voo de todo o país. O alarme das dez e dois, quinze, por se curar e ser arquivado como sem impacto. Cinco por cento para o milissegundo, pelo seu tempo. Raio de explosão. A Nats planejou cerca de oito mil voos naquele dia e tratou
Raio de explosão: 8.000 planejados, 6.094 tratados, terceira falha em três anos
2:27 cerca de seis mil. As partidas do Reino Unido pararam por cerca de quatro horas e meia, e o atraso levou mais de dois dias para ser resolvido. É a terceira falha de tráfego aéreo da Grã-Bretanha em três anos, e o diretor executivo chama esse bug de muito, muito obscuro.
Veredito + a linha de segunda-feira: escritas atômicas, alarmes altos
2:41 Veredito, post-mortem: NEEDS REVIEW. O relatório é rápido e específico, e a correção está escrita e em teste. Mas o plano é um reinício mais rápido, não um menor. Linha de segunda-feira: se uma tarefa pode ser pausada, torne sua escrita atômica, e trate um alarme que se cura como um alarme. Envie-me o incidente sobre o qual você ainda não tem permissão para falar, nos comentários, ou em thedailydiff.dev. E essa é a diferença de hoje.
3:02 Eu sou o Niko da Axrisi. Faça o merge com responsabilidade.
Fontes
- NATS, Major Incident Preliminary Investigation Report, NAS incident 08 September 2026 (report date Sep 16)www.nats.aero
- NATS press release, "NATS publishes preliminary report on technical incident of 8 September" (Sep 18, 2026)www.nats.aero
- NATS on X, 8 Sepx.com
- BBC, "Flight chaos caused by 'millisecond' software defect, report says"www.bbc.co.uk
- The Guardian (Sep 18, 2026)www.theguardian.com
- Hacker News thread on the reportnews.ycombinator.com



