Um erro de um milissegundo parou o tráfego aéreo do Reino Unido. Seis horas.
Às 10:00 de terça-feira, 8 de setembro, um pedido de código squawk de rotina dentro do Sistema Nacional de Espaço Aéreo (NAS) da NATS é interrompido por uma mensagem de prioridade mais alta enquanto está a meio de uma atualização de valor.
Às 10:00 de terça-feira, 8 de setembro, um pedido de código squawk de rotina dentro do Sistema Nacional de Espaço Aéreo (NAS) da NATS é interrompido por uma mensagem de prioridade mais alta enquanto está a meio de uma atualização de valor. A janela de exposição é de cerca de um milissegundo. O pedido retoma incorretamente, os dados de voo saem corrompidos, e até às 19:30 mais de 2.000 voos no Reino Unido foram atrasados, cancelados ou desviados.
Ler a edição escrita (Inglês) ↗
O que este vídeo aborda
- 10:00: um pedido, interrompido dentro de uma janela de 1 ms
- Cronologia: 10:00 squawk → 10:02 blip → 12:45 paragem de partidas → 13:32 ligação perdida
- A cura: reiniciar os dados de voo de todo o país
- Mecanismo: pausado a meio de uma escrita
- Porque é que uma funcionalidade 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: um pedido, interrompido dentro de uma janela de 1 ms
0:00 Às dez da manhã, um pedido de rotina dentro do sistema de dados de voo da Grã-Bretanha é interrompido exatamente no milissegundo errado, e ao fim da tarde mais de dois mil voos são atrasados, cancelados ou desviados. Isso é do relatório preliminar da Nats, o serviço de tráfego aéreo do Reino Unido. Nenhum sinal de ataque, e ninguém pressionou o botão errado. Apenas um defeito legado, e um milissegundo muito específico. Como aconteceu, porque um milissegundo foi suficiente, e quem realmente leva a culpa. Este é The Daily Diff, postmortem.
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 paragem de partidas → 13:32 ligação perdida
0:36 liga um ponto de radar ao seu plano de voo. O pedido é válido, assim como o plano. Dez e dois. A ligação entre o Controlo da Área de Londres e o sistema central cai, depois volta sozinha após quarenta e cinco segundos. O bilhete diz recuperado, estável, sem impacto operacional. Doze e trinta e dois. A ligação 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 paradas. À uma e trinta e dois, a ligação cai e permanece inativa. 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 controlo e aeroportos em todo o país. O erro vive no espaço aéreo de Londres. As restrições cobrem todo o Reino Unido. O reinício decorre das três e um quarto às quatro e dez, e o desenrolar dos planos de voo duplicados leva até às sete menos dez. Então, por que um milissegundo foi suficiente?
Mecanismo: pausado a meio de uma escrita
1:23 O sistema lida com trabalhos por prioridade, e pausar um pequeno trabalho por um urgente é normal. Mas este trabalho estava a meio de uma atualização de valor. A mensagem urgente chega dentro desse milissegundo, e a atualização para a meio. Quando retoma, não retoma corretamente. Os dados errados depois vazam para algumas das atualizações de voo posteriores.
Porque é que uma funcionalidade de segurança parou o céu
1:40 Londres tenta ler um, demora muito e esgota o tempo. Um tempo limite derruba a ligação, como projetado, para proteger ambos os sistemas. A funcionalidade 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 garantida para acontecer até terça-feira desta semana. Foi 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 a meio e volta errada. O plano de reinício, trinta, porque um registo mau em Londres significa reiniciar os dados de voo de todo o país. O alarme das dez e dois, quinze, por se curar sozinho e ser arquivado como sem impacto. Cinco por cento para o milissegundo, pelo seu tempo. Raio de explosão. A Nats planeou cerca de oito mil voos naquele dia e tratou
Raio de explosão: 8.000 planeados, 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 este erro de muito, muito obscuro.
Veredito + a linha de segunda-feira: escritas atómicas, alarmes altos
2:41 Veredito, postmortem: 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 um trabalho pode ser pausado, torne a sua escrita atómica, e trate um alarme que se cura sozinho como um alarme. Envie-me o incidente sobre o qual ainda não lhe é permitido falar, nos comentários, ou em thedailydiff.dev. E essa é a diferença de hoje.
3:02 Eu sou o Niko da Axrisi. SHIP IT.
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



