Transport Operations Lab

A year of incidents, turned into the three answers an operations review actually needs: what it cost, what really caused it, and which fix returns the most uptime per pound.

Three questions, and why they get answered wrongly

What did it cost?

Two people can read the same log and reach different availabilities, honestly, because two conventions differ: whether planned work counts, and whether a partial outage counts in full. Neither is wrong, and the argument in the review is nearly always about which convention was used rather than about the numbers.

Say which one you used. An availability figure without its convention is not a measurement.

What caused it?

Incident counts are what everybody has. They come out of the ticket system, they are easy to sort, and they are the wrong unit. Downtime is frequency times duration, and the element that generates the most tickets is frequently the one whose failures are shortest — because short failures are noticed, logged and closed, while the four-hour outage on a quiet element is one ticket.

Rank by minutes. If the two rankings disagree, that disagreement is the most useful thing in the review.

What should we fix?

The instinct is to fix the thing that broke most recently, or most loudly. The useful comparison is minutes returned per pound spent, because that is the only unit in which a spares contract and a redundant line card can be compared at all.

And there is a systematic asymmetry worth knowing: repair time is shared. Spares, access arrangements, a rehearsed runbook — those apply to every element at once, so a modest across-the-board improvement competes against the whole log, while eliminating your worst element competes only against that element. On a log with no dominant cause, the boring process fix usually wins outright.

Three failures cannot measure an MTBF

Divide the observation window by the number of failures and you get a number that looks like a measurement. With a handful of failures it is barely more than a rumour.

For a time-terminated observation the confidence interval on MTBF comes from the chi-squared distribution, and with three failures over a year the 90% interval spans roughly a factor of four. The point estimate sits inside a range wide enough that almost any improvement claim fits.

This matters because MTBF numbers get quoted in reviews and written into plans. Ten failures is about where the estimate starts to mean something — and even then only if the failure rate was roughly constant across the window, which after a big remediation it was not.

Zero failures is its own trap. It gives a lower bound and nothing else: an absence of failures is not evidence of a long time between them.

What this does not do

It does not diagnose. Grouping incidents by element is bookkeeping, not root cause, and repeated short outages within a few hours usually mean one underlying fault reported several times — which inflates the failure count and flatters the repair time at the same moment.

It assumes the intervention does what you say it does. A 30% cut in repair time is an input, not a prediction: whether spares on site actually deliver that is a question about your organisation.

It says nothing about whether the target was reasonable, whether the credit scheme is fair, or whether the money is better spent elsewhere entirely.

Everything is calculated in your browser. Incident data, element names, fees and costs are not uploaded.