In short: On 8 September 2026, a software defect with a window of about one millisecond disrupted UK air traffic. An edge case is a rare situation at the limits of what a system expects, like an interruption at exactly the wrong moment. Edge case testing looks for those situations on purpose, before production finds them for you.

On Tuesday 8 September, a defect in the UK’s air traffic control system caused hours of restrictions across UK airspace. The UK Civil Aviation Authority counts more than 2,000 flights that were delayed, cancelled or diverted. Ten days later, air traffic provider NATS published a preliminary report. The cause was a bug in a small part of the system. It could only go wrong within about one millisecond.

That is a textbook edge case, and the lessons apply to any team that runs software people depend on.

What happened on 8 September?

According to NATS, the defect sat in a small part of the National Airspace System. That part gives aircraft an ID code, which controllers use to spot flights on radar. While it was handling such a request, the system was interrupted by a message with a higher priority. After that message, it did not correctly pick up the task it had paused. The window in which this could go wrong was about one millisecond. Only flights in the London Area Control centre were affected, mostly higher-level flights. Even so, restrictions applied across the UK so the system could be restarted safely. They lasted about six hours, and clearing the backlog of disrupted passengers took more than two days. NATS found no sign of a cyber attack and says the incident is unrelated to its 2023 failure. A temporary fix is in place while a permanent fix is safety tested.

The CAA has started an independent review. It will look at how NATS renews its key systems, what it did with earlier advice and how well the CAA itself keeps watch. A first report is due by the end of January 2027, the final report by 8 March 2027. The NATS report does not say how the defect got past testing, so we won’t guess.

What is an edge case in testing?

An edge case is a situation at the limits of what a system expects. It is rare, but it can happen. In testing, it means a mix of input, timing or conditions that normal use almost never creates. Some edge cases sit at a boundary, such as the highest amount a form accepts, or the last second before midnight. Others sit in timing, such as two users saving the same record at the same moment, or a task that is interrupted halfway through. The NATS defect belongs to the second group: an interruption at one specific moment. Edge cases are easy to miss because the everyday test flow never reaches them. A tester clicks through the happy path, where everything arrives in a neat order. The system in production handles thousands of events, and some of them will arrive at the wrong moment.

Why do timing bugs slip through normal testing?

Timing bugs slip through because most tests run one step at a time, in a neat order, on a quiet system. A test sends a request, waits for the answer and checks it. Nothing else happens in between. Production is not like that. Messages arrive at the same time, urgent work jumps the queue and tasks get paused and picked up again. A bug that needs one event to land inside a window of one millisecond may pass thousands of test runs without showing up. It also means that running the same test again rarely reproduces it. That is why teams can say “we tested it” and be right, while the defect is still there. To find these bugs, you need tests that create busy, messy conditions on purpose. You also need runs that repeat often enough to hit the rare moment.

How do you test for edge cases you can’t predict?

You can’t list every edge case in advance, but you can make them far more likely to show up in testing than in production. Start with the ones you can name. Then make your tests as busy and messy as real life. Let automated runs repeat often enough to hit the rare moment. Five techniques help:

• Boundary values: test just below, on and just above each limit. The ISTQB calls this boundary value analysis.
• Interruptions: pause long tasks with urgent work and check that they resume correctly.
• Load: send many requests at once, with urgent messages mixed in.
• Fault injection: slow down a service, drop a connection or restart a component halfway through a task.
• Repetition: run automated tests every night with varied data and timing. The rare combination then gets thousands of chances.

For the Blankenburg Connection tunnel near Rotterdam, we tested at a special test site that copied the real systems as closely as possible. There we faked broken equipment, tunnel emergencies and real traffic.

Why should you test recovery as well?

Every system fails at some point, and recovery decides how much the failure costs. In the NATS case, the defect lasted a millisecond and the restrictions lasted about six hours. Most of the impact came after the defect: stopping safely, starting again and clearing the backlog. The same applies to a web shop, a bank or a logistics platform. Test the restart itself. How long does it take? What happens to transactions that were halfway? Who decides to switch back on? If a recovery procedure has never been tried, nobody knows how long it takes. Run it in a test environment on a regular schedule, and time it. At the Blankenburg Connection, failover tests showed that the backup systems took over at once, without a break.

What this means for your team

Pick one process where a failure would really hurt. List its boundaries, its long-running tasks and the moments where it can be interrupted. Write a test for each one, and add them to your automated regression suite so they run every night. Then test the recovery once, with a stopwatch.

Nekst builds and runs these tests alongside your team. With Test Automation as a Service, your regression suite, edge cases included, runs every night and we keep it running. For roads, locks, plants and other critical systems, our Smart Industry Solutions team tests the control software in real-world conditions.

Frequently asked questions

What is an edge case in testing?

An edge case is a rare situation at the limits of what a system expects. Think of a maximum value, two actions at the same moment or a task that is interrupted halfway. Edge case testing creates those situations on purpose to see how the system behaves.

What are examples of edge cases?

An order of exactly the maximum amount. A date on the night the clocks change. Two users editing the same record at once. A task that is interrupted and has to resume. The NATS defect of 8 September was an interruption at one precise moment.

What is the difference between use cases and edge cases?

A use case describes how people normally use a system, such as placing an order. An edge case is a rare variation at the limits of that use, such as placing an order while the payment service restarts. You need both: use cases for the main flow, edge cases for what can go wrong around it.