A Millisecond Software Bug Disrupted UK Airspace for Days
Matthew Mbaka · September 19, 2026 · News
A software error that unfolded in the space of a millisecond forced restrictions across UK airspace for six hours and disrupted more than 2,000 flights.
The computer problem was brief. The recovery was not.
NATS, the company that runs much of the United Kingdom’s air traffic control system, published a preliminary investigation report on September 18. It traces the September 8 failure to a previously unknown defect in legacy software used to manage flight data.
NATS says the incident was not a cyberattack and was not caused by military or civilian operators. A full investigation is due within 60 days.
A normal request met a badly timed interruption
The affected system allocates identification codes, often called squawk codes, that allow air traffic control to match an aircraft with its flight plan and radar track.
A manual code request was being processed when a higher-priority message arrived. The system paused the first request, handled the new message and then returned to the original work.
The defect appeared when processing resumed. The request did not continue correctly, flight data became corrupted and some later updates were affected.
The failure was local to the London Area Control system, which manages higher-level traffic over England and Wales. NATS still imposed restrictions across the UK while engineers restarted the core National Airspace System and reloaded flight data.
Controllers could continue speaking with aircraft and watching them on radar. They used manual fallback procedures, but that extra workload meant fewer aircraft could safely enter each sector.
Why the disruption lasted much longer than the outage
NATS expected to handle about 8,000 flights that day. It handled 6,094. Its preliminary count says more than 2,000 flights were delayed, cancelled or diverted.
Normal operations returned that evening, yet airlines and airports needed more than two days to clear the backlog. Aircraft were out of position. Crews reached duty limits. Passengers who missed one connection competed for limited seats on later flights.
This is common in tightly connected systems. Restoring the failed computer is only the first recovery milestone. The service around it may need much longer to settle.
That distinction matters to Canadian travellers using UK airports or crossing the North Atlantic. A status page can show the technical incident as resolved while the practical disruption is still moving through airline schedules.
The harder questions come next
NATS has already put a mitigation in place while a permanent fix is tested and safety-assured. The full report should go beyond the faulty code.
It needs to explain why the rare sequence was not caught earlier, whether the interrupted transaction left enough evidence for faster diagnosis, and how much traffic the fallback system can handle before restrictions spread nationally.
Software used in critical infrastructure cannot be tested against every possible timing combination. It can be designed to fail more cleanly. Interrupted work should either resume from a known safe state or be discarded and started again. Corrupted data should not quietly affect later transactions.
The investigation should also examine the recovery plan outside NATS. Airlines and airports need procedures for putting aircraft, crews and passengers back into place after the technical service returns.
NATS kept aircraft safe by reducing capacity. That was the right choice. The uncomfortable part is how a tiny software timing error created a disruption measured in days, thousands of flights and hundreds of thousands of travel plans.
Tags: aviation, software failure, air traffic control, operational resilience, travel