A Millisecond Glitch Disrupted 2,000 Flights. Could Your Systems Do the Same?

Published 2 October 2026

One millisecond isn’t enough time to blink, sip your coffee or mutter something unprintable at your printer.

It is, however, enough time for a software defect to cause trouble on a national scale.

On 8 September 2026, a previously unknown defect in the UK’s air traffic system corrupted flight data when two routine events collided within an estimated one-millisecond window. The resulting disruption affected more than 2,000 flights and hundreds of thousands of passengers.

One millisecond was all it took for two routine events to collide.

The system had operated for years without triggering that exact sequence. Then a normal request arrived at precisely the wrong moment.

That should make any tech person slightly uncomfortable.

What happened next should be on the radar of every IT manager, MSP and consultant responsible for keeping critical systems running.

NATS, formerly National Air Traffic Services, reported that aircraft remained safely separated throughout the incident. The lesson for IT teams lies elsewhere: in the small, improbable software failure that sits quietly inside an established system until it one day announces its presence with a vengeance.

Timing Is Everything

The preliminary NATS investigation(opens in new tab) provides an early root cause analysis of the failure, tracing the problem to a software module that allocates identification codes to aircraft.

A manual request was being processed when a higher-priority message arrived. The system paused the original task, dealt with the more urgent one, and then returned to what it had been doing.

Except it didn’t resume correctly.

A latent defect corrupted the output and affected later flight-data updates. For the failure to occur, the higher-priority request had to arrive while the original request was partway through updating a value. That’s all it took. One millisecond earlier or later and everything would have worked normally.

Nothing about the request or its associated flight plan was unusual, and the operator had followed the correct procedure. The defect emerged only because a routine event arrived at exactly the wrong moment.

That’s the part worth carrying back to your own environment. Testing usually proves that expected inputs produce expected results. It may also cover malformed data, unavailable services and excessive load. But what happens when two perfectly valid transactions arrive in a sequence nobody thought to simulate?

Recovery Can Look Like Resolution

The first visible warning appeared at 10:02 a.m., when the connection between two systems dropped. It restored itself after approximately 45 seconds. Health checks found no hardware fault and the environment appeared stable.

For more than two hours, there was no obvious operational impact. Everything seemed fine … until the problem reared its head again.

At 12:32 p.m., failures in the data connection between London Area Control and the National Airspace System became more frequent. The controllers kept losing the connection that supplied their system with flight plans and other live flight data.

An hour later, that connection failed completely. Controllers lost access to some of the flight data and automation they ordinarily relied on, forcing them to coordinate aircraft handovers with neighboring control centers manually.

Once again, the fallback procedures kept aircraft safely separated, but they couldn’t support anything close to normal traffic levels. Departures from UK airports were stopped for approximately four and a half hours during the six-hour incident. Arrivals were restricted and some aircraft already in the air had to be diverted. What began as corrupted data inside a single software module had become a nationwide disruption affecting airlines, airports and passengers.

The alert disappears, everyone exhales and the defect waits for another chance.

This can happen in any IT department. A service may reconnect and appear healthy even though the fault that interrupted it is still there. The alert disappears, everyone exhales and the defect waits for another chance.

Teams need to preserve logs, correlate events across connected systems and investigate unusual recoveries before the same fault returns under less forgiving conditions.

For IT teams, a root cause analysis shouldn’t stop at identifying the defect that triggered an incident. It should also examine how the damage spread, why recovery mechanisms didn’t contain it and whether fallback processes are sufficient.

Can the Fallback Carry the Real Workload?

NATS had documented fallback procedures to rely on, and its controllers receive annual training in using them. The fallback worked in the most important sense: aircraft remained safely separated.

A fallback process that can handle five requests may buckle under five thousand.

But maintaining safety required controllers to handle some tasks manually, and manual processing took longer. The system could continue operating only at sharply reduced capacity. Once the core system restarted, engineers still had to reconcile duplicate flight plans, mismatched records and data that had fallen out of sync across connected systems.

That’s a familiar pattern well beyond aviation, right?

Your business may have a manual process for approving orders, transferring files, validating records or responding to customer requests when automation fails. Someone may even have tested it with five dummy transactions.

But could it cope with five thousand real transactions on a Monday morning?

A fallback process isn’t resilient merely because it exists. It needs enough people, access, documentation and processing capacity to handle production demand. The recovery plan must also account for the mess that accumulates while systems are separated: duplicate work, conflicting versions, missed updates and records that no longer agree.

Getting the application running again is only part of the job. The records scattered across connected systems still have to be checked and reconciled.

Start with the questions most likely to make the room go quiet as the mental cogs kick into high gear …

Rare Doesn’t Mean Harmless

The defect’s one-millisecond exposure window explains how it could remain hidden, but it doesn’t reduce the damage when the required conditions finally align.

Before 8 September, this particular sequence had never occurred, but that track record offered no protection when it did.

Legacy software deserves particular attention, but age alone isn’t the issue. Mature systems often carry years of integrations, exceptions and dependencies. A local error can travel through interfaces and databases before users even understand what’s happened. By then, a technical fault may have become an operations problem, a customer-service problem and an executive problem.

The 8 September failure is now part of an even more uncomfortable story. On 21 September, NATS experienced a second technical incident at its Prestwick center. NATS said the two failures were unrelated, but the later disruption led to further delays and cancellations across Scotland, Northern Ireland and northern England. According to the Associated Press(opens in new tab), 227 flights had been cancelled by late afternoon.

Maybe two unrelated failures are more revealing than two related ones because they shift attention from one defective module to the resilience of the wider operating environment.

Ask the Uncomfortable Questions Now

I doubt anybody can predict every potential millisecond timing conflict, but you can examine how your organization detects, contains and recovers from failures it didn’t predict.

Start with the questions most likely to make the room go quiet as the mental cogs kick into high gear:

Somewhere in your own systems is an equally improbable failure already waiting for its one millisecond of infamy?

Can one malformed or badly timed transaction disrupt an entire service?
Do monitoring systems distinguish an automatic recovery from a genuine resolution?
Has the manual fallback been tested at real production volume?
Which connected systems will fall out of sync during an outage?
Who decides whether to restart, isolate or continue at reduced capacity?

How will duplicate, missing or conflicting data be reconciled afterward?
Which “impossible” edge cases have escaped testing because they’ve never happened?

The same questions apply during a server refresh, cloud migration or storage reorganization. A file may move successfully while the links inside it still point to its former location. An application may come back online while documents, spreadsheets and databases no longer connect as expected. The visible system can look restored before the dependencies that make the data useful are repaired.

LinkFixer Advanced(opens in new tab)^™ helps organizations identify, protect and repair links inside files during data migrations and reorganizations. It addresses one specific but easily overlooked class of dependency that can turn a technically completed move into a business disruption.

One millisecond is difficult to imagine. More than 2,000 disrupted flights aren’t.

One hidden defect can disrupt every connected system and dependency.

The lesson isn’t that every rare defect should be found in advance. It’s that resilience is tested after the improbable arrives. Containing the immediate damage is only the beginning. The business must also keep functioning while the fault is repaired and then make sure its systems and dependencies are truly working again.

Somewhere in your own systems is an equally improbable failure already waiting for its one millisecond of infamy?

By Ed Clark