Machine-Level vs Line-Level OEE: Which View Finds the Constraint?

Choose the unit of analysis by how tightly your assets are coupled, and choose it before you build the reporting.

On independent machines, machine-level OEE is the operating truth and a line-level roll-up hides which asset is the problem. On a coupled line, the reverse holds: individual machines can each post a strong number while the line loses output, because a machine that is starved or blocked is not producing but is not broken either. Changing the unit later invalidates your history, which is why this decision deserves ten minutes now rather than an argument in six months.

Machine vs line OEE at a glance

Starved and blocked, defined

Two states that exist only on coupled equipment, and that most OEE configurations handle badly.

Starved. The machine is available, staffed and capable of running, and has nothing to work on because the upstream equipment is not delivering. Nothing is wrong with it.

Blocked. The machine is available and capable, and cannot run because the downstream equipment cannot accept its output. Again, nothing is wrong with it.

Both are distinct from idle, which implies the machine could have run and did not, and from down, which implies a fault. A starved machine is a symptom of somebody else's problem, and the reason this matters is that most reporting configurations do not have a state for that.

Guidewheel's bottleneck analysis guide gestures at the dynamic when it observes that everything downstream starves and everything upstream backs up. That is the right intuition, and turning it into a measurement requires giving the two conditions their own states rather than folding them into idle.

What goes wrong without them. A starved machine logged as idle looks like an asset with an availability problem. Someone is dispatched to investigate a machine that was working correctly all shift, while the constraint that actually caused the loss reports its own downtime as a much smaller number, because it was down for forty minutes while three neighbours were starved for forty minutes each. The reporting attributes 160 minutes of loss across four assets, of which one is the cause and three are consequences, and nothing in the numbers distinguishes them.

Configuring them is not free. Detecting starved and blocked usually requires knowing the line topology, which upstream feeds which downstream, and that has to be defined rather than inferred. It is worth the effort on any genuinely coupled line, and it is wasted effort on independent assets.

Which is why the coupling question comes before the reporting question.

When machine OEE misleads

When the assets are coupled, machine-level numbers can all look acceptable while the line loses a third of its output.

A worked case. A four-station line: infeed, process, inspect, pack. An eight-hour shift, 480 minutes of planned production time.

The process station suffers a 60-minute failure. During that hour, infeed runs briefly and then blocks because its output has nowhere to go. Inspect and pack starve immediately.

Recorded per machine, with starved and blocked folded into idle:

Four stations averaging 88% availability. Nothing on that table looks like a crisis, and an improvement team reading it would reasonably conclude the line is broadly healthy with a small distributed availability problem.

The line produced nothing for 60 minutes. Line availability is 87.5%, and the entire loss came from one station. The other three were working correctly.

The two errors this produces. First, effort is spread across four assets instead of concentrated on one. Second, and worse, the process station's 88% does not stand out from its neighbours, so the constraint is statistically invisible in exactly the report that was supposed to find it.

It compounds with micro-stops. Repeat the pattern with twenty two-minute stops instead of one long one and the machine-level numbers converge even further, while the cumulative line loss is identical. Given that Guidewheel's downtime analysis shows the events that hurt most are frequently not the longest ones, this is the common case rather than the exotic one.

Line-level reporting fixes this, and introduces a different blindness.

When line OEE misleads

When you need to know which asset to fix, and the line number will not tell you.

Take the same shift. Line OEE reports 87.5% availability and a clear loss of 60 minutes. Correct, and useful for the plant manager reporting output. Entirely useless for the maintenance planner, because it does not say which of the four stations caused it.

Where this bites hardest. A line whose OEE drifts down over a quarter, with no single dramatic event. The line number falls from 82% to 76% and nobody can say why, because the cause is distributed: a slightly slower infeed, a marginally less reliable inspect station, a pack station stopping more often for consumable changes. Each is invisible at line level, and each is obvious at machine level.

The second failure mode is aggregation across dissimilar lines. A site that averages line OEE across a well-balanced line and a badly balanced one produces a number that describes neither. Multi-site rollups do this routinely, and the resulting comparison between plants is largely an artefact of how each plant drew its line boundaries.

Line boundaries have to be defined consistently or cross-site comparison fails before it starts. If plant A treats the packer as part of the line and plant B treats it as a separate downstream asset, their line OEE figures are not comparable no matter how carefully both were measured. This is the same class of problem as the definitional boundaries covered in the OEE data governance definition sheet, and it should be settled in the same standard.

So each view is correct about a different question, and the answer is not to pick one permanently.

Choosing the unit

The coupling test. For any two adjacent assets, ask: if one stops for ten minutes, does the other stop producing? If yes, they belong to the same line and the line is the unit. If no, they are independent and the machine is the unit.

Apply it pairwise across the floor and the natural line boundaries fall out. Buffers complicate it usefully: a buffer large enough to absorb a ten-minute stop decouples the assets on either side for stops under that length and not for longer ones. Where that is the case, define the line by the stop duration that matters to you rather than pretending the buffer is infinite.

Then choose per context, because the right unit differs by purpose.

• Constraint analysis: machine level, with starved and blocked separated, so the causal asset is distinguishable from its neighbours. Then use bottleneck analysis to work the constraint.
• Shift review: line level first for whether the line delivered, then machine level for why. The pairing logic mirrors the one in schedule adherence versus OEE.
• Multi-site rollup: line level, with line boundaries defined identically across sites, or the comparison is meaningless.
• Capital justification: machine level, because the case is about a specific asset.

Decide before you build. Changing the unit later invalidates the history, and a year of machine-level data cannot be retrospectively converted into line-level data because the starved and blocked attribution was never captured. This is the single strongest argument for spending ten minutes on the coupling test now.

Benchmark context is worth a caution here too. Guidewheel's 2026 Factory Uptime Report puts U.S. factory uptime at 54.5% with a 31-point gap to the top quartile, which is useful for calibration and useless as a target unless you know whether the basis was machine or line.

Getting both without double counting

You can report both views. One rule makes it safe: the line number is the truth, the machine numbers are the explanation, and they are never summed or averaged together.

What that means in practice.

• The line figure is what gets reported upward and tracked over time. It is the plant's output performance.
• Machine figures exist to attribute the line's loss. They answer "which asset", not "how much".
• Never average machine OEE to produce line OEE. In the worked case above, the four stations average 88% availability while the line achieved 87.5%, and those numbers agreeing closely is a coincidence of that example rather than a relationship. On a line with different cycle times per station, averaging produces a figure with no physical meaning at all.
• Never sum machine downtime to produce line downtime. The worked case would give 235 minutes of machine downtime against 60 minutes of line downtime, because three of those stoppages were consequences of the fourth.

Present them together, in order. Line availability and its loss, then the ranked machine contribution to that loss with starved and blocked shown separately. A reader should be able to see in one view that the line lost 60 minutes and that all of it originated at the process station. Guidance on building that view is in designing an OEE dashboard, and the formula both views share is in the complete guide to OEE.

One configuration prerequisite. None of this works unless starved and blocked are captured as distinct states, which means the line topology has to be defined. That is a setup task, not an analysis task, and skipping it is why so many plants have machine-level data they cannot use to explain a line-level result.

Frequently asked questions

About the author