Last night, November 13, 2026, the FAA ordered a nationwide ground stop in the United States. Air traffic was disrupted by a failure in the infrastructure used to coordinate it. The Hawaiʻi Tourism Authority’s notice records the order and its subsequent lifting: departing flights were halted, while inbound international flights were handled individually.

Transportation Secretary Sean Duffy described a very old air traffic control system. He attributed the interruption to communications equipment, switches and routers that had become overloaded and were providing inconsistent data. The Department of Transportation’s statement records that explanation and the reopening of the airspace. This is the initial official account, rather than a definitive technical root cause analysis.

The age of these systems was already documented. In September 2024, the Government Accountability Office —GAO— reported that the FAA had classified 51 of its 138 air traffic control systems as unsustainable, citing problems including outdated functionality and a lack of spare parts.

I find it difficult to read these stories without thinking about how little we value the work that prevents something from happening. Well-maintained infrastructure usually produces an unremarkable result: the train arrives, the aircraft departs, the hospital provides care, the application responds. Another ordinary day.

And precisely because it seems ordinary, it becomes tempting to treat the money that makes it possible as optional.

Urda and Adamuz: demanding answers while investigations remain open

The connection with the Urda and Adamuz railway accidents immediately comes to mind. It also calls for care: relating these events to infrastructure maintenance does not establish a shared cause.

In Urda on October 28, 2026, an AVE train struck a stationary Iryo train. RTVE’s reconstruction identifies a computer failure affecting the LZB train protection system, operation under degraded conditions, and instructions exchanged between the control center and drivers among the matters being investigated. Accounts conflicted, and the investigation remained open.

In Adamuz, where the accident occurred on January 18, 2026, investigators have focused on a rail fracture or its weld. EFE reported on November 5 that inquiries and requests for renewal and maintenance records were continuing. That investigative focus does not constitute a final conclusion about what caused the fracture or who was responsible.

My shared concern is how we establish that infrastructure remains safe throughout its working life, and what happens when one of its protections stops working.

In US aviation, stopping departures was a safety response to a loss of confidence in the system. That deserves attention too. An organization needs to be able to reduce activity or stop when it cannot guarantee the conditions required to continue. Pressure to maintain service needs clear limits, workable procedures and people authorized to apply them.

Maintenance requires a political and business decision

Building something new makes an opening ceremony possible. Maintaining what exists means explaining why we need to spend money so that tomorrow we still have what we take for granted today.

Something similar happens in a software company. A new feature can be demonstrated in a presentation. An updated library, a rehearsed data restoration or the removal of a dangerous dependency is barely visible from outside.

That creates an incentive I find troubling: postponing work whose benefits are difficult to show. If the system keeps running, another deferral seems defensible. Accumulated risk stays outside the conversation until it becomes an interruption, a loss or a tragedy.

The relationship between maintenance and safety, however, has investigated precedents. We do not need to anticipate findings about recent accidents to defend it.

Three precedents in physical infrastructure

Mianus River, 1983: an inspection that misses deterioration

On June 28, 1983, a section of the I-95 bridge over the Mianus River in Connecticut collapsed. Three people died. The NTSB’s probable cause finding identified undetected movement of components in the suspension assembly caused by corrosion-related forces, linking it to deficiencies in the state’s bridge inspection and maintenance program.

An inspection needs resources and methods capable of establishing the actual condition of the relevant components. Its administrative existence does not guarantee that it serves that purpose. In software, we should remember this whenever an audit is satisfied merely by confirming that a procedure exists.

Hatfield, 2000: knowing about a problem requires resolving it

In the Hatfield derailment of October 17, 2000, the rail fractured because of fatigue defects. The Railway Safety & Standards Board report preserved by The Railways Archive identified failures in inspections, management of maintenance and renewal contracts, and delivery of an urgent rail replacement that was never completed.

The analogy with a known software vulnerability is difficult to ignore. Recording a defect begins the work. Reducing the risk requires action, an owner, a deadline and verification afterward. A problem can be thoroughly documented and remain dangerous.

Fern Hollow, 2022: repeated recommendations left unimplemented

Pittsburgh’s Fern Hollow Bridge collapsed on January 28, 2022. The NTSB investigation linked the failure to corrosion and section loss in a critical structural component. Clogged drains allowed water and debris to accumulate. The city had failed to act on repeated maintenance and repair recommendations; inspection and oversight deficiencies also contributed.

I think about the warnings that reappear in every review of a computer system. A repeated alert can become part of the scenery. That is why we need to check which recommendations have been implemented and what evidence allows us to close them. Finding the same observation in consecutive reports should trigger a decision.

Software needs upkeep too

Code does not rust like a piece of steel. The comparison has that limit, and we should preserve it.

But the context of the service that depends on that code changes: vulnerabilities emerge, workloads grow, equipment is replaced, interfaces change, certificates expire and vendors end support. People who understand the reasons behind particular decisions also leave.

A program can retain precisely the same bytes while becoming increasingly difficult to operate safely. Maintaining it therefore includes its dependencies, data, infrastructure, procedures and the team’s knowledge.

Technical debt describes some of this outstanding work. Managing it means being specific: which component poses a risk, what its failure would mean, who can intervene, and how long replacement or recovery would take. The expression loses its usefulness when it becomes a general label that lets everything wait.

Five incidents that help explain the problem

WannaCry and the NHS, 2017: an available fix that never reaches the machines

According to the National Audit Office, NHS organizations infected by WannaCry had unpatched or unsupported Windows systems. Alerts had advised applying fixes, but there was no formal mechanism for checking compliance. The attack disrupted healthcare services and led to thousands of canceled appointments and operations.

My reading is that publishing an instruction leaves considerable operational work: inventorying equipment, checking compatibility, scheduling the intervention and verifying the result. That requires people and dedicated time. Security also depends on whether the organization makes the maintenance it demands possible.

Equifax, 2017: a vulnerability and monitoring that also failed

GAO report 18-559 describes an Apache Struts vulnerability left unpatched on the portal affected by the Equifax intrusion. An outdated recipient list prevented the notice from reaching those responsible for installing the patch. An expired certificate also prevented inspection of encrypted traffic, making the extraction of data harder to detect.

This example broadens what I understand by maintenance: inventories, notification channels and the monitoring mechanisms themselves need upkeep too. A security tool can remain deployed after we have lost the protection we believe it provides.

Knight Capital, 2012: the code we leave behind remains there

On August 1, 2012, an incorrect deployment activated a defective function retained in Knight Capital’s order routing system. The SEC documented inadequate deployment and testing controls. The firm accumulated unwanted positions and lost more than $460 million in roughly 45 minutes.

Removing code that should no longer be used is maintenance. So is knowing which version each server runs and having controls that limit the damage. Updating part of a system requires understanding its interactions with the rest.

GitLab, 2017: recovery also needs maintenance

After production data was accidentally deleted on January 31, 2017, GitLab discovered problems with its recovery mechanisms. Its postmortem explains that logical backups failed because of incompatible PostgreSQL versions and that error emails were rejected. Nobody owned regular testing of that procedure. Recovery used an earlier snapshot, and some recent database data was lost.

Having a task named “backup” provides a limited guarantee. We need to know whether we can restore, what we would lose and how long it would take. Periodic exercises let us establish that before depending on the answer during a crisis.

The FAA, 2023: an intervention can also affect the backup

Last night’s episode has a different precedent in January 2023. The FAA reported at the time that contract personnel had unintentionally deleted files while correcting synchronization between the NOTAM system’s primary and backup databases. That outage also led to a ground stop.

My reading of that incident is that two systems need effective separation of their failure modes. A replica and a recoverable backup serve different purposes. Designing and rehearsing how to survive an incorrect operation is part of maintaining a critical service.

Analogies help us decide what to do

These correspondences offer a way of interpreting the cases; they do not assert identical causes or consequences:

Nor does the comparison equate an application outage with lives lost in an accident. Consequences depend on the service. That is precisely why we need to identify software involved in critical functions and apply the appropriate rigor.

Modernization requires control over change

Supporting maintenance investment does not mean recommending indiscriminate updates. On July 19, 2024, a CrowdStrike content update caused Windows systems to crash. Its root cause analysis describes a mismatch between expected and supplied input fields. Subsequent measures included additional checks and phased deployments.

That case shows why a modernization budget must also cover testing, transition and recovery. We need to assess both the risk of keeping a component and the risk of changing it. A well-understood older system may warrant gradual replacement; a component without support or spare parts may require more urgent action.

The decision needs information about the service and its risks. Age alone does not establish a system’s safety. Nor does the word “new” guarantee that we have integrated it correctly.

Investment whose results we can verify

If I were asking those responsible for infrastructure or a software product to make a commitment, I would start with specific measures:

• Funding throughout its working life. Purchasing or construction should include a plan for maintenance, renewal and retirement.
• An inventory with owners. What we have, its dependencies, its support status and who is responsible for it.
• Time for intervention. Windows for inspection, fixes and testing, with resources to resolve incompatibilities.
• Defect follow-up. Prioritize by consequences, record deferrals and verify repairs before closing a warning.
• Demonstrated recovery. Restore backups and rehearse alternatives against recovery time and data loss targets appropriate to the service.
• People able to sustain the system. Training, documentation and continuity of knowledge.
• The ability to stop. Clear criteria for reducing or suspending activity when safety conditions require it.

We can review how long important defects take to fix, when restoration was last tested, or which components are approaching the end of support. Those answers help determine where to invest and whether the money is reducing risk.

Not every failure demonstrates inadequate maintenance, and no investment prevents every accident. Even so, investigated cases provide sufficient reasons to take this work seriously and demand that it be done properly.

I want to be able to trust the infrastructure I use. That trust needs more than a promise that it worked yesterday: it needs people, funding, useful inspections and problems that get resolved.

Maintenance is part of building something worth keeping in operation. What will sustain the service ten years from now should also inform the decisions we make today.

Information checked through November 14, 2026. References to Urda and Adamuz describe open investigations; the analogies and investment proposals are the article’s reflection.

Photographs and the interface screenshot have been resized and converted to WebP. The Mianus image was cropped from the report page to isolate the photograph, retaining its annotations. Each file retains the license stated in its caption; context images are explicitly identified.