Nowlan and Heap found 68 percent of United Airlines items were most likely to fail right after maintenance, and that scheduled overhaul raised the failure rate.

Two Percent Wear Out. Sixty-Eight Percent Are Most Dangerous Right After You Touch Them.

TL;DR: Reliability data from the aviation industry proves that 68% of complex systems follow a failure pattern defined by "infant mortality," where they are most likely to break immediately after a maintenance intervention. For modern engineering teams, this means scheduled maintenance windows often concentrate risk rather than reducing it, as the act of intervention itself resets the failure clock.

A 520-page report the industry is quoting from memory

There is a statistic frequently cited in software engineering circles: "89 percent of failures are random." It is often used to justify why uptime is hard to predict or why traditional monitoring fails. However, this is a mangled misquote of a seminal 1978 report that actually says something far more actionable for SREs and VPs of Engineering.

The primary source is Reliability-Centered Maintenance by F. S. Nowlan and H. F. Heap, a report commissioned by the U.S. Department of Defense and published by United Airlines (Report AD/A066 579). According to Nowlan and Heap, the data does not say failures are random; it says that 89 percent of items cannot benefit from a limit on operating age.

When you look at Exhibit 2.13 on page 46 of the report, the researchers plot the conditional probability of failure against the age of the component. They identified six distinct patterns. The actual distribution of items across these patterns was:

Pattern A: 4% (Traditional wear-out)
Pattern B: 2% (Bathtub curve)
Pattern C: 5% (Gradual increase)
Pattern D: 7% (Low initial failure, then random)
Pattern E: 14% (Constant random failure)
Pattern F: 68% (Infant mortality)

The finding wasn't that the world is random. It was that the majority of failures are caused by the very acts intended to prevent them.

Pattern F, at 68 percent, is the one to read

Pattern F is the most significant finding for anyone managing a production environment. The report describes Pattern F as exhibiting "infant mortality, followed by a constant or very slowly increasing failure probability." Crucially, the report notes this pattern is "particularly applicable to electronic equipment."

The horizontal axis of these charts is critical: it represents the "operating age since manufacture, overhaul, or repair." In other words, the clock restarts every time a human or a script touches the item.

Key Takeaway: The majority of system failures are not caused by components growing old, but by the "infant mortality" triggered the moment a change is introduced.

This means that if your system is in Pattern F, it is at its most dangerous in the seconds, minutes, and hours following an intervention. By "fixing" or "maintaining" a system that is currently stable, you are not buying reliability; you are spending it to reset the clock to the highest-risk period of its lifecycle.

The sentence that should be in every change-management document

Aviation engineering in the 1970s was a high-stakes laboratory for reliability. They ran the experiment of scheduled maintenance on a massive scale and the results were sobering.

As stated on page 48 of the report, "scheduled overhaul actually increases the overall failure rate by introducing a high infant-mortality rate." The report goes further on page 50, noting that "high early failures after a shop visit could be due to a problem in shop procedures."

Translated to 2026, a "shop visit" is a deploy, a configuration push, or a dependency upgrade. When we batch these changes into a "maintenance window," we are essentially forcing our systems through a massive shop visit. If your team notices that incidents cluster on Tuesday mornings after the Monday night maintenance window, you aren't seeing bad luck. You are seeing Pattern F in action. Your procedures are generating the very failures they were meant to forestall.

Mapping it onto software, carefully and with the disanalogies named

To apply Nowlan and Heap to software, we must distinguish between material fatigue and logical complexity. Software does not "wear out" in the physical sense. A binary does not rust; a function does not develop stress fractures. Therefore, Patterns B and C (wear-out) have very few direct analogues.

However, software does have a small subset of failure modes that genuinely rise with elapsed time:

TLS certificates approaching expiry.
Disk space and log volume consumption.
Database index bloat and statistics decay.
Credential rotation windows.
Partition range exhaustion.

These are the "2 percent." They belong on a calendar or a clock. Everything else—code changes, dependency bumps, infrastructure migrations—falls into Pattern F. The honest conclusion is that while calendars are vital for a specific, enumerable minority of failure modes, most teams mistakenly apply a calendar-based "age-limit policy" to their entire stack.

What this says about your maintenance window

If you are a VP of Engineering or a CTO, you can run a simple exercise to audit your reliability strategy. Sort your scheduled operational work into two lists:

Clock-Based Work: Tasks where the probability of failure genuinely rises as time passes (e.g., certificate rotation, disk cleanup).
Condition-Based Work: Tasks scheduled on a calendar out of habit (e.g., quarterly dependency upgrades, monthly patch windows).

Work in the second list does not become safer because you waited three months to do it. In fact, batching these changes into a single window concentrates the "infant mortality" risk. It creates a massive spike in the conditional probability of failure at the exact moment your team is most likely to be fatigued or understaffed.

The 2026 version of the problem

In the modern era, the frequency of change has skyrocketed. With the rise of AI-generated code and automated infrastructure-as-code updates, a large share of system changes are now generated rather than handwritten.

If Pattern F holds, the primary risk to your uptime is not the code "aging" in production. The risk is how often you reset the infant mortality clock. A team shipping four times as often is resetting that clock four times as often. The operational answer to this increased frequency is not a more rigorous quarterly review meeting; it is continuous condition monitoring after every change.

What condition-based actually requires

Moving from a calendar-based to a condition-based maintenance model is only viable if detecting the "condition" is cheaper than running the schedule. In 1978, aviation achieved this through better instrumentation and non-destructive testing.

In software, this requires an observability layer that can distinguish between a real regression and noise immediately after a change. Most teams fall back to the calendar because they lack the capacity to watch every deploy, every config change, and every dependency bump with the necessary depth.

This is why we built Operate. Operate watches for these conditions continuously rather than on a schedule—tracking exceptions, silent failures, slow queries, and schema drift across your entire stack. It doesn't just alert; it investigates the root cause with evidence and drafts the fix as a PR. By moving from a calendar to a self-hosted, privacy-first AI SRE, you can stop spending your reliability budget on unnecessary "shop visits" and start managing by condition.

Sources & further reading

According to the primary source, F. S. Nowlan and H. F. Heap, Reliability-Centered Maintenance (1978), only a small fraction of components show a classic wear-out pattern.
The NASA RCM Guide clarifies the origin of various reliability labels used in the industry.
Practitioners at Accendo Reliability have noted that the "89 percent random" claim is a widespread misunderstanding of the original United Airlines data.