OEE vs TEEP vs OOE: Which Metric Should You Use?

The OEE vs TEEP question comes up as soon as a plant asks whether it needs more machines or just better use of the ones it has. All three metrics discussed here, OEE, OOE and TEEP, use the same performance and quality factors; what differs is the time they are measured against. This article explains each one, works through a single example to show how far apart they can be, and lists the MQTT signals you need to calculate all three automatically.

The Short Answer

• OEE measures how well you use the time you planned to produce. Use it to improve operations on the floor.
• OOE measures how well you use the time the operation is open, including planned stops inside that time. Use it when breaks, meetings and planned maintenance are part of what you want to reduce.
• TEEP measures how well you use all the time there is, every hour of every day. Use it for capacity and investment decisions.

If you are running an improvement program on a line, OEE is the right daily metric. If someone is about to buy another machine, look at TEEP first.

Time Bases Side by Side

Each metric divides productive time by a different denominator:

So the formulas become:

• OEE = Fully productive time / Planned production time
• OOE = Fully productive time / Operations time
• TEEP = Fully productive time / Calendar time

Another way to write TEEP is OEE x Loading, where Loading = Planned production time / Calendar time. That form is useful because it separates two questions: how well do we run when we run (OEE), and how much do we schedule the asset (Loading).

One Worked Example, Three Answers

Consider one machine over a week:

1. Calendar time: 7 days x 24 hours = 168 hours.
2. Operations time: two shifts of 8 hours, five days a week = 80 hours.
3. Planned stops inside operations time: breaks and meetings of 1 hour per shift = 10 hours, plus 4 hours of planned maintenance. Total 14 hours.
4. Planned production time: 80 - 14 = 66 hours.
5. Unplanned stops: 8 hours of breakdowns and changeovers. Run time = 58 hours.
6. Performance: 90 percent. Quality: 97 percent.

Fully productive time = 58 x 0.90 x 0.97 = 50.6 hours.

• OEE = 50.6 / 66 = 76.7 percent
• OOE = 50.6 / 80 = 63.3 percent
• TEEP = 50.6 / 168 = 30.1 percent

Same machine, same week, three very different numbers. None of them is wrong. OEE says the floor runs the planned hours reasonably well. OOE says planned stops take a meaningful bite out of open hours. TEEP says the asset is producing good parts less than a third of the time it exists, which means the plant has plenty of hidden capacity before it needs another machine: a third shift or weekend operation would add far more output than any improvement project.

When to Use Each Metric

Use OEE when you want to reduce losses that operators, maintenance and engineering can influence during the shift: breakdowns, changeovers, micro-stops, speed and scrap. It is the right metric for daily meetings and line boards. The detailed calculation is in how to calculate OEE.

Use OOE when planned stops are themselves a target. Examples include staggering breaks so the line keeps running, shortening shift handovers or moving planned maintenance to non-operating hours. OEE cannot show those gains because planned stops are excluded from its denominator.

Use TEEP when the question is about capacity: buying equipment, adding shifts, outsourcing or taking a large new order. A low TEEP with a decent OEE usually means scheduling, not equipment, is the constraint.

Common traps:

1. Comparing OEE across plants with different planned-stop rules. One plant counts changeovers as planned and reports a higher OEE without being better. OOE exposes this.
2. Reporting TEEP to the floor. Operators cannot influence unscheduled weekends, so TEEP is demotivating as a shift metric.
3. Moving losses into "planned" to improve OEE. If OEE rises while OOE stays flat, look at what was reclassified.

The MQTT Signals Each Metric Needs

The good news is that all three metrics come from the same data, as long as stops are classified correctly. Publish per machine:

The critical part is the classification of non-running time. If an idle machine at night simply reports STOPPED, you cannot tell an unplanned breakdown from an unstaffed weekend. Either publish NOT_SCHEDULED from a shift calendar service, or let the calculation service apply the calendar. Clear downtime reason codes with a separate "Planned" category make this mapping reliable.

Calculating All Three in Python

Given state durations for a period, this function returns all three metrics. It is meant to sit inside a service that subscribes to the state and count topics, such as the one built in the real-time OEE monitoring tutorial.

def time_metrics(durations_s, total_count, reject_count, ideal_cycle_s):
    """durations_s: seconds per state over the period, e.g.
    {"RUNNING": ..., "DOWN": ..., "SETUP": ..., "PLANNED_STOP": ..., "NOT_SCHEDULED": ...}"""
    calendar = sum(durations_s.values())
    operations = calendar - durations_s.get("NOT_SCHEDULED", 0)
    planned = operations - durations_s.get("PLANNED_STOP", 0)
    run = durations_s.get("RUNNING", 0)
    if run <= 0 or total_count <= 0:
        return {"oee": 0.0, "ooe": 0.0, "teep": 0.0, "loading": 0.0}

    performance = min(ideal_cycle_s * total_count / run, 1.0)
    quality = (total_count - reject_count) / total_count
    productive = run * performance * quality
    return {
        "oee": round(productive / planned, 4),
        "ooe": round(productive / operations, 4),
        "teep": round(productive / calendar, 4),
        "loading": round(planned / calendar, 4),
    }


hours = 3600
week = {
    "RUNNING": 58 * hours,
    "DOWN": 5 * hours,
    "SETUP": 3 * hours,
    "PLANNED_STOP": 14 * hours,
    "NOT_SCHEDULED": 88 * hours,
}
# 58 h run, 90 % performance -> ideal output = 58 h * 0.9 at 2 s per part
total = int(58 * hours * 0.9 / 2.0)
reject = round(total * 0.03)
print(time_metrics(week, total, reject, 2.0))

The output reproduces the example: OEE about 0.767, OOE about 0.633, TEEP about 0.301 and loading about 0.393. Publish the result as one retained message per machine and period so dashboards can show the right metric to the right audience.

To try the data flow, publish test states to the public MQTT test broker at broker.connectmq.com under your own prefix:

mosquitto_pub -h broker.connectmq.com -p 1883 -i teep-test-w2k8 -r -t "connectmq/demo/w2k8/plant1/line1/press02/state" -m '{"state":"NOT_SCHEDULED","ts":1792200000}'

Hosting the Pipeline

The metrics are only as good as the event stream behind them, so the broker must be reliable and private. A shift calendar service publishing NOT_SCHEDULED, gateways publishing states and counts, and a calculation service publishing results can all share one ConnectMQ broker as ordinary MQTT clients. ConnectMQ provides a fully managed MQTT service where every gateway and calculation service has its own credentials over TLS, and running it as a cloud MQTT broker gives plant and corporate teams one source for OEE, OOE and TEEP. The smart manufacturing guide explains how these metrics fit alongside quality, energy and maintenance data.

Get Started with ConnectMQ

Create a free Serverless broker at app.connectmq.com with no credit card, publish classified machine states and counts, and calculate OEE, OOE and TEEP from the same live data.

Frequently Asked Questions

Is TEEP always lower than OEE?

Yes, or equal at most. TEEP divides the same productive time by calendar time, which is never shorter than planned production time.

What is the difference between OOE and OEE?

OOE uses operations time as the base, so planned stops such as breaks and planned maintenance count as losses. OEE excludes them.

Which metric should go on the line board?

OEE, with its three factors. It reflects losses the shift can influence; TEEP belongs in capacity and investment reviews.

Do I need extra sensors for TEEP?

No. You need the same machine states and counts as for OEE, plus a clear NOT_SCHEDULED classification from a shift calendar.