At 13:46 on Tuesday 8 September, National Air Traffic Services reported a fault in the flight processing system at its Swanwick centre in Hampshire. Engineers had a fix in place by 16:40. In the three hours between those two updates, roughly 1,300 flights to and from UK airports were cancelled, Ryanair counted 65,000 disrupted passengers, and British Airways cancelled or diverted more than 100 services. Another 246 cancellations were on the Heathrow board by 06:00 the next morning. Anyone who runs transaction processing at volume will recognise the shape of it.
The fault sat in flight data handling rather than radar or communications. Flight processing systems take the plans airlines file and turn them into the picture controllers work from: which aircraft is going where, at what altitude, through whose sector. When that data can't be trusted, the safe response is to reduce the number of aircraft allowed into the system and let controllers work manually. Runways, aircraft and crews were all available on Tuesday afternoon, and capacity was still set by a data pipeline.
The 2023 failure and the architecture question
Almost the same category of system took out a UK holiday weekend three years ago. In August 2023, an airline filed a plan containing two identically named waypoints (a waypoint is a fixed navigational reference point) in different parts of the world. The software couldn't resolve which was which, shut itself down as a safety measure, and handed the work to controllers to key in by hand. The backup did the same thing, because it was running the same code against the same input. Around 700,000 passengers were affected, and airline bosses put their costs above GBP 100m in refunds and compensation. A separate Swanwick outage in July 2025 held up departures for more than four hours.
NATS hasn't disclosed what triggered Tuesday's failure, and chief executive Martin Rolfe told the BBC it was unlike anything seen in fifty years. What's confirmed is that the same class of system failed again. Redundancy built by duplication defends against hardware failure; identical software receiving identical input produces identical results, so a parsing edge case reaches the primary and the standby in the same instant. The Civil Aviation Authority's review of 2023 asked for better contingency planning. Heidi Alexander, the transport secretary, summoned Rolfe for a meeting on Wednesday.
Transaction processing breaks the same way
Between 31 January and 2 February 2025, Barclays customers spent three days unable to move money. The bank told the Treasury Committee the cause was a software problem in a critical module of its UK mainframe operating system, which produced progressively severe degradation of processing performance. Of the customers who logged in and tried to submit a payment, 56% failed. Barclays expects to pay between GBP 5m and GBP 7.5m in compensation for that incident, and up to GBP 12.5m across its recent outages.
That mainframe carries debit cards, deposits and overdrafts. The failure was ordinary: a module degraded, throughput fell, and the bank narrowed what it could safely accept. Swanwick made the same decision about departures.
Nine UK banks and building societies reported at least 158 IT failures to the Treasury Committee between January 2023 and February 2025, adding up to 803 hours of unplanned outage, more than 33 days. The causes they gave were system changes, third-party suppliers, software bugs and hardware faults. TSB remains the reference case: its April 2018 migration to a new core platform hit technical failures immediately, affected a customer base of 5.2 million, took until December to return to normal running, and produced a GBP 48.65m regulatory fine alongside GBP 32.7m in customer redress.
TSB is also why plenty of boards leave a working mainframe alone. Migration is where the risk concentrates, so an ageing core that clears payments every day looks like the conservative option. It stays conservative until a module degrades, and then the institution is running a manual process at national scale.
A payment switch under stress behaves like a flight processing system under stress. A switch routes each transaction to the right processor or network, and when it slows, authorisation requests queue. Timeouts propagate out to acquirers and issuers, which apply their own retry logic, and those retries arrive as fresh traffic on a system already behind. Operators then throttle deliberately rather than accept requests they can't settle. The expensive work starts after the fix: establishing which timed-out authorisations actually completed, which reversals posted twice, which balances are wrong, and which of them a customer has already seen. Reliable transaction processing gets judged on that recovery as much as on uptime.
Systems built in the last decade treat the bad record differently. A malformed message gets quarantined so one input can't halt the pipeline. Failover runs on an independent path rather than a mirror of the primary. Writes are idempotent, meaning a retried authorisation posts once however many times it arrives. Degradation narrows to a subset of rails and payment types instead of stopping. Queue depth is visible while the backlog forms. None of that is novel engineering, and it's still missing from systems carrying a large share of the world's card volume.
Some institutions make the calculation explicitly: running at very high availability costs more than recovering quickly, so occasional outages get accepted as the cheaper option. That calculation prices minutes. Tuesday cost NATS three hours and cost airlines most of a week repositioning aircraft and crews, plus UK261 obligations (the rules covering compensation for delayed and cancelled flights) on every affected passenger. Barclays' three days produced a compensation bill before anyone counted the value of the payments that failed. The regulator, the select committee and the transport secretary all arrive at the same place afterwards: the recovery belongs to the institution, and it runs far longer than the incident.
