Two lines can report the same interruption rate while one is healthy and the other is quietly falling apart. The difference is the stop threshold, a configuration choice that can turn a chronic problem into a clean-looking number. Here's how the illusion works, and the index that breaks it.
Put two lines side by side. Both report an interruption rate in the low teens. One is genuinely stable. The other is stopping every fifteen seconds. Nothing in the headline number tells them apart, and that is exactly the problem. The variable doing the hiding is the stop threshold.
A stop threshold is the delay before a pause is logged as downtime. Set it aggressively, at 30 seconds, and almost every stop shows up. Set it leniently, at 5 minutes, and a great deal disappears: operators clear the fault and restart the line before the timer ever trips a breakdown code.
One studied line reported a comfortable 12.86% interruption ratio, apparently optimised. Its real time between stops was 15 seconds. The generous 5-minute buffer let operators absorb a relentless stutter of faults invisibly, so the chronic problem, and the mechanical stress behind it, never reached a single management report.
Worse, the trick works in two directions at once: it inflates the interruption ratio's apparent stability while deflating unplanned downtime, because the breakdowns that would have been coded got resolved under the timer instead.
To standardise across lines with wildly different thresholds, we use the Threshold Exposure Index:
It asks a simple question: how does a line's actual time between stops compare to the buffer it's allowed? The 12.86% line above scored a TEI of just 5.06%, stopping roughly twenty times faster than its threshold, an unmistakable red flag. A line with an aggressive threshold and long runs, by contrast, scores well above 100% and can be trusted. Any low TEI is a warning that the reported numbers are masked.
The payoff of stripping the illusion is sharper analysis everywhere. Across the raw portfolio, MTBI and unplanned downtime correlated at a weak r = 0.41. Filter to the honest, high-TEI lines and the correlation jumps to r = 0.73. The buffer wasn't just hiding losses, it was hiding the relationships that explain them.
Check the TEI before you trust any downtime report. The buffer illusion is one of the core findings of the Interruption Whitepaper, and the reason MTBI should never be read on its own.
It's the delay a line waits before counting a pause as downtime. Below the threshold, a stop may be treated as an interruption or ignored; above it, the stop is logged with a reason code. Thresholds in the study ranged from 30 seconds to 5 minutes.
With a lenient 5-minute buffer, operators can clear a fault and restart the line before any breakdown code triggers. The chronic stopping never reaches the downtime report, so the line looks far healthier than it is and its unplanned downtime looks artificially low.
TEI = MTBI ÷ stop threshold × 100. It normalises time-between-stops against the configured buffer. A low TEI (well under 100%) means the line is stopping far faster than its threshold, so its reported numbers are masked and untrustworthy.
Because masked breakdown data weakens every downstream analysis. In the study, filtering out low-TEI lines lifted the correlation between MTBI and unplanned downtime from r=0.41 to r=0.73, the noise was hiding the real signal.