Availability loss analysis breaks the availability factor of OEE into its causes, breakdowns, setups and changeovers, and unplanned minor stops, so you can see where scheduled run time actually goes. It turns a single number like "86% available" into a ranked list of minutes lost, which is what you need to fix anything.
Knowing your availability rate tells you how much time you lost. It does not tell you to what. A line at 86% availability lost 14% of planned production time, but a line that lost it to one long breakdown needs a different fix than a line that bled the same minutes across forty short jams. Availability loss analysis is the step that separates those two plants. This guide covers the loss categories, how to bucket real downtime records, and how to turn the result into the two or three actions that matter.
What is availability loss analysis?
Availability loss analysis is the practice of taking total downtime, the gap between planned production time and run time, and splitting it into named, countable buckets you can act on. Instead of "we lost 63 minutes," you get "28 minutes breakdown on the filler, 25 minutes changeover, 10 minutes minor stops," ranked by size.
It matters because availability is usually the largest and most improvable of OEE's three factors, and because its losses are lumpy. A handful of causes typically own most of the lost minutes, so a ranked split points straight at the work. The analysis feeds directly from your downtime log and rolls straight back up into the OEE calculation it is the diagnostic layer between the two.
What are the categories of availability loss?
Availability losses fall into two firm categories plus one gray zone. In the six big losses framework, availability owns exactly two of the six:
- Breakdown / failure loss (unplanned downtime). The equipment stopped when it was supposed to run: mechanical failure, jams that need real intervention, tooling breakage, a tripped safety. These are the stops people notice, and they connect to reliability metrics like MTBF and MTTR.
- Setup and adjustment loss (changeover). The line was planned to produce and was instead being converted, cleaned between products, or dialed in after a change. This is planned in the sense that you knew a changeover was coming, but it still subtracts from availability. It is often the fastest loss to cut, because setup-reduction methods work without capital spend.
- Minor stops, the gray zone. Very short unplanned stops (a jam cleared in under a couple of minutes, a sensor fault reset by hand). By convention, stops below your logging threshold land in the performance factor rather than availability, because they are too brief to log individually. Where the line is drawn is a decision you make once; the important thing is knowing which side each stop is on.
How do you run an availability loss analysis?
Work from real downtime records, not impressions. The sequence:
- Pull the downtime records for the period. Every logged stop with its start, duration, and reason code. Longer periods smooth out one-off events; a week or a month usually reads truer than a single shift.
- Assign each stop to a bucket. Breakdown, setup/changeover, starvation/blockage, or planned. Clean up vague reason codes now, "misc" and "other" are where insight goes to die.
- Sum minutes per bucket and rank them. Total lost minutes by category, largest first. This is a Pareto in the making.
- Convert to availability points. Divide each bucket's minutes by planned production time to see how many availability points it costs. This translates "40 minutes" into "9 points of OEE" that leadership can weigh.
- Attack the top one or two. The biggest bucket almost always deserves the first project. Breakdown loss routes to reliability and root-cause work; setup loss routes to changeover reduction.
- Re-run next period and watch the shape. A good analysis is repeated. Watch the top bucket shrink and, often, a different one rise to the top, the constraint moves.
A worked example, ranked by minutes
These numbers are hypothetical one week on a made-up filling line, planned production time of 2,250 minutes (five 450-minute shifts).
| Loss bucket | Minutes | Availability points |
|---|---|---|
| Changeover / setup | 190 | 8.4 |
| Breakdown, capper | 120 | 5.3 |
| Starvation (upstream) | 75 | 3.3 |
| Logged minor stops | 50 | 2.2 |
| Total downtime | 435 | 19.3 |
Run time is 2,250 − 435 = 1,815 minutes, so availability = 1,815 ÷ 2,250 = 80.7%. The Pareto is clear: changeover and one recurring capper fault own 310 of the 435 lost minutes, about 71%. A setup-reduction effort plus one root-cause fix on the capper would move availability more than anything aimed at the smaller buckets. That is the whole point of the analysis: it tells you the two projects worth staffing.
How does planned versus unplanned downtime factor in?
Availability loss analysis has to be honest about a boundary: some downtime is planned, and OEE handles it two ways depending on where it sits. Planned maintenance windows and breaks are excluded from planned production time entirely, so they never touch availability. Changeovers, though scheduled, happen inside planned production time and do count against availability. The distinction that matters for improvement is planned versus unplanned:
- Unplanned downtime (breakdowns, jams, starvation) is the volatile, expensive kind. It is unpredictable, it wrecks schedule adherence, and it is where reliability programs pay off.
- Planned-but-avoidable downtime (changeover, adjustment) is predictable and steadily reducible. You know it is coming; the work is making it shorter.
Splitting the two changes the conversation. Unplanned loss says "we have a reliability problem." Planned-avoidable loss says "we have a setup problem." Different owners, different tools, different projects.
How does availability loss connect to MTBF and MTTR?
Breakdown loss is where availability meets reliability engineering. Two reliability metrics decompose it further: mean time between failures (MTBF) measures how often the equipment fails, and mean time to repair (MTTR) measures how long each failure keeps it down. Breakdown minutes are, roughly, failure count multiplied by average repair time, so you can shrink the bucket from either side: fewer failures or faster recovery.
That is a useful cross-check on your fix. If breakdown loss is many short stops, the lever is MTBF, attack the recurring fault so it stops happening. If it is a few long stops, the lever is MTTR, spares, procedures, and response so recovery is faster. Availability loss analysis tells you which shape you have before you pick the wrong lever. It also connects to your andon metrics since response time to a call is part of MTTR, and to throughput since availability loss on the constraint machine is the only availability loss that actually costs you units.
The same logic caps how much a fix is worth. An hour recovered on a machine that is starved or blocked half the day buys nothing; an hour recovered on the bottleneck buys real output. So before staffing an availability project, confirm the loss you ranked is on a machine whose uptime the line actually depends on, otherwise you will improve a number without improving the plant.
How big are availability losses in practice?
Bigger than most plants admit before they measure honestly, and the macro data hints at why. The U.S. Federal Reserve's G.17 industrial production release put manufacturing capacity utilization at 75.7% in May 2026 about 2.5 percentage points below its 1972–2025 average. Capacity utilization is a broader measure than availability, it includes shifts a plant chose not to run, but it is a plain reminder that real factories operate well below their theoretical maximum, and unplanned availability loss is a large slice of the gap.
Two reference points frame the target. The commonly cited world-class availability factor is 90% part of the 90% × 95% × 99% split that yields the familiar 85% OEE benchmark from Seiichi Nakajima's TPM work, a reference, not an audited standard. And within availability loss, changeover is frequently the largest single bucket on lines with any product variety, which is why setup-reduction methods so often top the improvement list. Neither figure replaces measuring your own line; both give you a sense of scale before you start.
What should you do with the result?
Turn the top buckets into staffed projects and re-measure. The discipline that makes availability loss analysis pay is repetition: the constraint moves, so the analysis has to be a habit, not a one-time audit. And it is only as good as the reason codes underneath it, a downtime log full of "other" produces a Pareto of nothing. That is the case for capturing stops at the source with structured reasons, so the analysis reflects what the equipment did rather than what someone remembered at shift end. Harmony logs stops from PLC and sensor signals with operator-added reason codes (see the platform or the CLS results), which is what makes the Pareto trustworthy shift after shift. From here, roll the improved availability back into the OEE calculation cross-check against plant KPIs and run scenarios in the OEE calculator.