Recurring Failure Patterns as a Discipline Signal

One outage is data; a pattern of outages is a diagnosis of the organization. Any facility of sufficient size and age will have a history of incidents, and the individual incidents matter less than the shape they form over time. Reading that shape is where outage intelligence becomes an assessment of operator discipline, which is the quality an investor is ultimately underwriting and a regulator is ultimately policing.

The first thing to look for is whether failure modes repeat. A mature, well-run operator produces a history of diverse, mostly shallow incidents: a variety of different triggers, each caught fairly quickly by the defenses, few of them reaching customers, and, crucially, few of them repeating. The diversity is a good sign because it means no single weakness dominates; the shallowness is a good sign because it means the barriers are doing their job; and the lack of repetition is the best sign of all, because it means that when something did get through, the operator found the cause and closed it. Contrast that with a history where the same failure mode recurs, the same subsystem, the same trigger family, the same phase of the timeline going wrong again and again. Repetition is the single most damning pattern in the field, because it proves the loop from failure to learning to correction is broken. The operator saw the problem, presumably wrote a postmortem, and yet the cause was never addressed. That is either a structural constraint they cannot fix within their budget or their real estate, or a culture that treats symptoms and never causes. Both are things you very much want to know before you commit capital or grant a permit.

The second thing to look for is the trajectory. Count not just how many incidents but how they trend as the facility ages and grows. Some operators show a maturing curve: incidents that become less frequent, less severe, and less customer-impacting over time as the organization learns its own plant and hardens its weak points. That curve is the fingerprint of a functioning learning culture, and it is worth paying for. Other operators show a degrading curve: incidents that grow more frequent or more severe, often because load has been added faster than the infrastructure and the operating discipline could absorb, so the facility is being pushed past the envelope it was designed for. A degrading curve near a facility running at high utilization is a serious warning, because it usually means the margins that used to absorb faults have been consumed by growth.

The third thing to look for is the character of the corrective actions across the history, read together rather than one at a time. When you line up several postmortems from the same operator, you can see whether their fixes are converging on architecture or endlessly circling around process. An operator who, after a barrier failure, invests in genuine physical separation, or replaces a shared fuel system with independent ones, or reconfigures a topology to remove a common-cause element, is spending money to remove classes of failure permanently. An operator whose every corrective action is another monitoring alert, another checklist item, another training reminder, is choosing the cheapest response each time, and while process improvements are real, a pattern of only process improvements after physical failures means the underlying architecture is never getting better. Over years, those two operators diverge sharply even if they started from the same design.

There is a subtler signal in how an operator handles near-misses, the events where a barrier was spent but the load survived because a second failure did not arrive. Disciplined organizations treat a near-miss with almost the seriousness of an actual outage, because they understand it as a fault tree that got all the way to the last barrier. If an operator's history shows that near-misses trigger real investigation and correction, that is a strong positive signal about culture, because it means they are managing risk proactively rather than waiting for customers to be harmed. If near-misses vanish without a trace and only full outages get attention, the operator is running closer to the edge than their outage count alone suggests, because they are not counting the times they got lucky.

Put these together, repetition, trajectory, the architecture-versus-process character of fixes, and the treatment of near-misses, and an outage history stops being a list of unfortunate events and becomes a portrait of an organization's competence and honesty. Two operators can have the same raw number of incidents and be completely different investments: one with diverse, declining, architecturally-corrected failures and a habit of chasing near-misses, the other with a repeating signature failure, a worsening trend, and a drawer full of checklists. The reading skill you have built lesson by lesson culminates here, in the ability to look at a body of outage history and render a verdict on the people who run the place, which is, in the end, the thing that determines whether the next fault becomes a non-event or a headline.