Photograph by the author, taken during one of many business trips, before airports started making me sick.

On Friday evening, November 13, 2026, the Federal Aviation Administration announced that the American air traffic control system was stable. A nationwide ground stop, issued shortly before four o’clock Eastern after controllers began seeing inconsistencies in radar data and communications, had been lifted at 8:15. Aircraft were departing again, controllers had returned to normal operations, and the immediate danger that had prompted the interruption was over.

The FAA had good reason to consider that a success.

The failure had affected 17 of the country’s 22 air route traffic control centers, destabilizing the systems responsible for coordinating thousands of aircraft. It was only the second nationwide ground stop since September 11, 2001. Controllers and pilots followed established procedures, aircraft already in the air landed safely, and the agency kept the airspace closed until it was satisfied that the underlying systems could be trusted.

Reopening the airspace did very little for the aircraft that were no longer where they were supposed to be.

More than 7,000 flights were canceled on Friday. Aircraft were sitting in the wrong cities, crews were running into duty-time limits, and passengers had missed connections that no longer existed. The Transportation Secretary warned that night that recovery would be slow, because planes and crews had to be repositioned. By Saturday evening, nearly 7,000 more flights had been canceled. The disruption continues into Sunday, even though the FAA’s infrastructure has been operating normally since Friday night.

That same week, Microsoft experienced a separate failure affecting Exchange Online and several connected Microsoft 365 services. A latent software defect, exposed during network maintenance, caused requests to accumulate until the affected servers exhausted their processing capacity. Microsoft’s engineers restored services in stages, verifying that the infrastructure could handle the returning demand, and by the weekend the company had announced that its services were restored. Healthcare organizations in the United Kingdom and Ireland were still working through what the interruption had left behind.

The two incidents were unrelated, but they share a distinction. In both cases, an organization responsible for essential infrastructure restored its systems and declared the incident resolved. In both cases, the people depending on those systems kept dealing with consequences that the restoration itself could not undo.

There is nothing dishonest about either declaration. A service can be restored while the world it supports is still recovering. But those are different conditions, and we should stop describing them as the same one.

What the Green Light Means

I work with systems whose health can be reduced, for operational purposes, to a set of measurable conditions. Services are available, scheduled processes complete, data arrives within expected intervals, and applications return the results their users expect. When something fails, the first obligation is to understand what stopped working and restore it. These are the basic disciplines of operating complex technology, and they matter because the people maintaining a system need a defensible way to know whether their interventions worked.

A database administrator cannot declare a database healthy based on whether a salesperson has finished preparing a quarterly forecast, and a network engineer cannot wait for every employee who lost connectivity to finish their interrupted work before declaring the network operational. Each has to assess the things they are responsible for, using measurements that correspond to the behavior of those things.

That establishes what restoration means. The service responds to requests again, its dependencies are functioning, the errors that prompted the incident have stopped, and the conditions that made the system unsafe or unusable have been addressed well enough to resume operations. These are legitimate measurements. Without them, recovery becomes a matter of intuition, which is a poor substitute for evidence when others depend on the result.

The difficulty is that the purpose of most infrastructure lies outside the infrastructure.

An airline does not operate flights merely to move aircraft between airports. People board those aircraft because they need to be somewhere, often at a particular time. The aircraft, its crew, the reservation system, and the air traffic control infrastructure all participate in making that journey possible, but none of them is the journey. Likewise, an email service exists to support communication, and the value of a message depends on what the recipient needs to do with it. A purchase order received after a shipping deadline has been successfully delivered. The shipment it was meant to authorize may already be late.

The operator and the person depending on the service are observing different parts of the same event, from positions shaped by what each is responsible for accomplishing. Neither is mistaken. The trouble begins when the narrower observation becomes the accepted description of the whole, and it usually does, for a simple reason: the organization that can measure the incident is also the one that gets to declare it over.

The Work That Didn’t Happen

There is a characteristic of interrupted work that makes recovery difficult to measure: time keeps passing while the system is unavailable.

Some lost work can be recovered. When an electrical failure stops a manufacturing line, the equipment can restart, an additional shift can be scheduled, and delayed orders can eventually ship. That recovery costs overtime and freight, but the original commitments are still reachable. Other interruptions are less forgiving. A meeting that was meant to happen before a decision is useless after it, and a delivery that arrives after an event has ended cannot serve the purpose for which it was ordered.

The ground stop illustrates the difference. For the aviation system, the problem was the inability to safely maintain normal traffic, and once that capability returned, the task became repositioning aircraft, reassigning crews, and accommodating passengers within the capacity that remained. For travelers, the problem was something else. At Chicago O’Hare alone, more than 700 flights were canceled on Friday, and some passengers simply gave up, renting cars or going home rather than waiting for a seat. Their trips were not delayed. They were abandoned. Reaching the destination eventually does not always accomplish the journey.

The same distinction appears in business systems, where it is easier to overlook because the consequences resemble ordinary work. A customer sends a time-sensitive request while the email service is unavailable. The request eventually reaches its recipient, and both parties receive confirmation that their systems are functioning again. But the recipient still has to determine whether the request remains relevant, whether some alternate action was taken, and whether the original deadline can still be met. A delayed message does not always produce a delayed decision. Sometimes the decision happens without it.

Recovering the technology cannot reconstruct information that was needed at a particular moment, and it cannot restore the opportunities that passed while that information was unavailable. So people compensate. They call instead of emailing, reschedule their meetings, purchase alternate transportation, repeat work they cannot verify was completed, and make provisional decisions with the information they have. Some of those accommodations are sensible and effective. Others introduce new costs or risks that become apparent only after ordinary operations return.

The Costs We Count

In the days following the ground stop, attention turned toward the economics. One preliminary scenario analysis placed hypothetical airline exposure in the hundreds of millions of dollars, while explicitly acknowledging that no verified loss total yet existed. That qualification matters, but it was the boundary of the calculation that caught my attention. Airline costs are reasonably measurable because airlines keep records of revenue, schedules, and the expenses of irregular operations. The estimate describes the incident from the perspective of the businesses operating the flights, because those are the businesses whose costs are counted.

Consider what happens when the question extends past them. In Denver, local reporting documented hotel rooms that might ordinarily cost around $100 being offered for $400 or $500, and some travelers found no rooms at all. In Wichita, a traveler whose flight had been diverted reported paying $648 for a rental car as vehicles became scarce. These were consequences of the same interruption, but they occupied different places in the economic record: an accommodation expense for an airline, additional room revenue for a hotel, a transaction for a rental-car company, and an unplanned charge on a traveler’s card.

The underlying picture is genuinely complicated. An expensive hotel room is partly a transfer of money from a traveler to a business rather than an equivalent loss of value, and some businesses benefited from the demand while others lost customers who never arrived. Separating transfers from wasted resources and vanished opportunities is precisely why a complete assessment is so difficult. We can estimate the cost of idle aircraft because the industry tracks the quantities required. It is much harder to value a missed appointment or a lost day of income, and some consequences are personal enough that a dollar figure would tell us very little about their significance.

None of this makes the airline estimates wrong. They are useful, carefully bounded descriptions of particular financial consequences. But in The Implied Zero, I described how the things excluded from an analysis disappear from the decision that follows, and the same mechanism operates when we describe something that has already happened. A bounded number becomes a headline, the headline becomes the familiar account of the incident, and the costs outside the boundary remain distributed among people who may never be asked what they experienced.

Those costs do not cease to exist because they are difficult to consolidate. They simply remain with the people who incurred them.

The Work That Kept Happening

The Microsoft outage examines the same problem from a different angle, and I think it is the more revealing of the two.

During the disruption, healthcare organizations across the United Kingdom published notices explaining which services were affected and what alternate arrangements were in place. NHS Essex established a temporary telephone number for providers needing to make referrals or raise urgent patient enquiries. South Central Ambulance Service reported that it could not send or receive email, affecting messages from healthcare professionals and the electronic referral of patients to other NHS services; its 999 and 111 systems and ambulance dispatch were unaffected, but repeat-prescription requests could not be processed through their usual route. NHS Supply Chain kept its warehouses and transport running while redirecting suppliers to an alternative portal, and by late afternoon reported that communications were flowing again, although backlogs remained. In Ireland, the Health Service Executive’s Healthmail service, used in prescription communications, became unavailable, and the HSE worked with medical and pharmacy organizations on alternatives, including paper prescriptions.

The available reporting does not establish widespread interruption of emergency treatment or demonstrable harm to patients. Several of these organizations specifically emphasized that essential care was continuing, and their contingency arrangements existed precisely to keep an infrastructure failure from becoming a clinical one. That is evidence of resilience, and it deserves to be recognized as such.

Resilience has a cost, even when it works. Someone had to establish those temporary telephone arrangements. Clinicians needed to understand which channels remained available, determine whether referrals had been received, and adjust their usual procedures. Administrative staff had to respond to additional enquiries, redirect messages, and eventually reconcile whatever had accumulated during the interruption. The fact that patients could continue receiving care did not make the outage inconsequential. It meant other people and processes had absorbed it.

I have written before about processes that appear to work only because people quietly compensate for their design. This is a different problem. There, the compensation hides a flaw in the system. Here, it relocates the cost of an incident into someone else’s ledger, where it is recorded as ordinary work. A failed service leaves an obvious record of its own unavailability. The call answered by a nurse, the paper prescription processed by a pharmacist, and the supplier reached through an alternate portal each appear as a successful transaction in another organization’s records. The effort required to produce those results is invisible to the provider whose failure made it necessary.

That produces a strange result: the people most successful at working around an outage are the least visible in its aftermath. Their customers received the expected service, and no failure appears in their operational record. What the record does not show is the work it took to make that outcome possible.

I would be cautious about inventing a total for that work. Not every additional telephone call represents a measurable economic loss, and some manual procedures were surely completed within normal staffing. But an organization can maintain continuity by consuming capacity it would otherwise have used for something else, and that cost tends to surface later as overtime, deferred routine work, reduced flexibility, or simply a more demanding day for the people keeping the service available. An aftermath that presents as business as usual is not evidence that nothing happened.

Where the System Ends

There is an obvious objection to this argument, and it deserves a direct answer: how far should responsibility extend?

Microsoft provides services to organizations that use them for purposes Microsoft does not control and may not even know about. The FAA manages the infrastructure necessary for safe aviation, but it does not operate the airlines, arrange passengers’ accommodations, or control the commitments travelers made at their destinations. No organization can be expected to understand every dependency built on its systems, much less answer for every consequence of their interruption, and attaching unlimited obligations to essential infrastructure would make it nearly impossible to operate or change. The organizations downstream have responsibilities of their own: airlines must plan for disruption, healthcare providers must maintain continuity procedures, and any business that depends on an external service needs to understand what that dependency costs when it fails.

The decisions that created the downstream costs were also the right ones. Allowing departures to continue on unstable radar data to avoid economic disruption would have been the wrong call, and a hurried restoration that overwhelmed Microsoft’s recovering infrastructure could have repeated the incident. The costs these decisions created do not make them less correct.

So the lesson is not that the organizations operating essential infrastructure should bear every downstream expense, or somehow become capable of measuring every human consequence of an outage. The problem is narrower than that, and more common: the boundaries of an organization’s authority tend to become the boundaries of its understanding.

An operator may have no practical ability to compensate a business for a missed opportunity, but that does not make the opportunity irrelevant to understanding the impact of the failure. A service provider may be unable to determine how many hours healthcare professionals spent compensating for unavailable communications, but that does not make those hours irrelevant when evaluating the resilience of the wider system. We can acknowledge that a consequence exists without deciding that the operator of the original service must bear its cost.

The gap matters because assigning responsibility is only one of the reasons we investigate failures. We also investigate them to understand how the effects propagated and what might reduce the consequences of similar incidents in the future. An investigation that stops where the infrastructure recovered can explain how the technology was repaired. It cannot explain what the disruption meant for the people using it, and the operator is often not the party best positioned to answer that question. The airline understands the operational cost of a canceled flight, while the passenger understands the consequences of missing it. Microsoft can explain what happened within Exchange Online, while a healthcare provider knows how its staff kept referrals moving. Neither holds a complete view of the incident, and combining their perspectives does not automatically produce one.

There may never be a complete account. But there is a meaningful difference between recognizing that completeness is impossible and allowing the measurable portion to stand in for everything that occurred.

Recovering the Purpose

In architecture, we usually discuss resilience in terms of what a system must be able to withstand: redundancy, failover, recovery objectives, and the conditions under which a service should stop rather than continue in a compromised state. These practices are valuable, and nothing here argues against them. But recovery has to mean more than returning infrastructure to its previous operating condition, because recovery creates load of its own.

A service returning after a prolonged outage receives accumulated demand far beyond its normal rate. Queued transactions begin processing, users retry failed requests, and automated processes attempt to catch up. Without controls, recovery can reproduce the overload that made the original incident difficult to resolve, which is exactly the risk Microsoft’s staged restoration was designed to manage.

The people depending on the system experience the same surge, and almost nobody designs for it. When email returns, the backlog does not simply flush. Delayed messages arrive after someone has already acted through another channel. Requests have to be checked for duplicates. Work that was merely accepted during the outage has to be distinguished from work that was actually completed. Each item in the queue now carries a question it did not carry when it was sent, which is why a backlog that took hours to accumulate can take days to clear. The technical system recovers in stages because its engineers planned for the surge. The human system recovers however it can.

I am not outside this. When I close an incident on a reporting environment, the evidence I use is evidence about the platform: pipelines executed, refreshes completed, models returning expected results. That evidence is necessary, and it tells me nothing about whether someone made a decision with incomplete information while the report was unavailable, reconstructed the result in a spreadsheet, or postponed the decision entirely. In some circumstances those questions matter more than the duration of the original outage, and my definition of resolved does not ask them.

That does not mean I should personally investigate every business decision made while a report was down. It means the architecture and the processes surrounding it should make it possible for the people affected to recognize what happened and decide whether anything else needs to be done. Sometimes that means preserving a record of interrupted transactions, or letting users distinguish work that was completed from work merely accepted for later processing. Sometimes it is simpler: make the limitation visible to the people who need to understand it.

In Second Place, I argued that a principle may lose, but it may not lose quietly, particularly when its consequences are carried by people outside the decision that produced them. Recovery deserves the same rule. An operator may not be able to remedy every consequence of an outage, but it can avoid making those consequences harder to discover.

This also changes how resilience should be judged. If a service can be restored in an hour only because dozens of downstream organizations must spend days reconciling its effects, then a one-hour recovery metric describes something real without describing everything that matters. The answer is not a universal measure, and it is not an ever larger model that assigns a value to every external cost; much of that would be precision manufactured from evidence that cannot support it. The answer is a more honest account. A credible recovery report should say what was restored, what remains uncertain, and which consequences fall outside the information available to its authors, and it should acknowledge known downstream effects even when they cannot be converted into an authoritative total.

That is less satisfying than a single number and a declaration of success. It is also a more accurate description of what happened.

After the All Clear

By Sunday, American aviation was approaching normal operations. Somewhere, a traveler was still absorbing an expense they had never planned to incur, and a business was trying to recover work that depended on a meeting or delivery that never took place. In the United Kingdom and Ireland, healthcare staff were clearing backlogs left by a failure that had already been fixed, and their success in keeping care running was itself part of what the incident cost.

We accept dependence on shared infrastructure because it allows us to do things we otherwise could not. In return, we owe one another an honest account of what happens when those dependencies fail: the limits of technical recovery, the costs carried outside the original incident, and the difference between a bounded measurement and the complete consequence.

An all clear tells us that something important has been restored. It does not tell us that everything it was meant to support has recovered.

The responsibility that remains after an incident is to remember the difference.