Tools
OEE calculator, with the formula and a worked example
Enter five numbers from one shift or one month, and the calculator gives you availability, performance, quality and overall equipment effectiveness (OEE). It also checks your inputs, because most wrong OEE figures come from one bad input rather than bad arithmetic.
Calculate your OEE
The OEE formula
OEE = Availability × Performance × Quality
- Availability = Run time ÷ Planned production time, where run time is planned production time minus downtime.
- Performance = (Ideal cycle time × Total parts) ÷ Run time.
- Quality = Good parts ÷ Total parts.
Multiply the three together and the run time and total parts cancel out, which gives a shorter version you can use as a check:
OEE = (Good parts × Ideal cycle time) ÷ Planned production time
If the long and short versions disagree, one of your inputs is in the wrong unit. Cycle time in seconds against production time in minutes is the usual culprit.
How to calculate OEE by hand: a worked example
A line is scheduled for 420 minutes. It stops for 60 minutes of unplanned downtime. Its ideal cycle time is 30 seconds (0.5 minutes) per part. It makes 600 parts, of which 570 are good.
- Availability. Run time is 420 − 60 = 360 minutes. Availability = 360 ÷ 420 = 85.7%.
- Performance. At the ideal rate, 600 parts would take 600 × 0.5 = 300 minutes. Performance = 300 ÷ 360 = 83.3%.
- Quality. 570 ÷ 600 = 95.0%.
- OEE. 0.8571 × 0.8333 × 0.9500 = 67.9%.
Check with the short formula: (570 × 0.5) ÷ 420 = 285 ÷ 420 = 67.9%. They agree.
Why an OEE dashboard can read 80% when the machines never ran that well
OEE is a composed number. Three factors multiply, and each factor depends on inputs that come from different places: a schedule, a downtime log, a cycle-time standard, a production count and a reject count. An error in any one of them carries straight through to the result, and the result still looks like a reasonable percentage.
That's what happened in one plant Antcluster worked with. The executive dashboard showed monthly OEE between 80 and 82%. The calculation used a cycle-time standard that had been set wrongly, even though the plant was recording observed cycle times all along. When the figure was recomputed against the observed cycle times, OEE came out far below the dashboard figure.
The plant didn't get worse when the number fell. The machines had been running at that level all along, and the investigation corrected the report management was reading. That matters more than it sounds, because a plant's capacity plans and investment cases usually start from its OEE.
Other ways an OEE figure drifts
- An ideal cycle time set too slow is the most common cause of inflated performance. A standard set years ago, or copied from a different product, lets the line beat it easily.
- When downtime gets classified as planned, every minute moved out of "unplanned" leaves planned production time and quietly raises availability.
- Counting rework as good inflates quality. Quality should count parts that were good first time.
- Averaging five machines' OEE percentages gives a different answer from computing OEE on their summed times and counts. Use the totals.
- A per-machine report that returns more rows than the plant has machines is double-counting something.
- If the reject count lives in another table or another system and isn't joined by line and date correctly, quality silently becomes 100%.
You can run any single shift through the calculator above and get a correct number. Checking months of dashboard figures this way, across every line, is a different job.
How Antcluster checks the numbers behind a dashboard
Antcluster connects read-only to the databases behind your dashboards and checks how the numbers are actually computed. OEE is one example. The same problem turns up in gross margin, on-time delivery, days sales outstanding and any other figure built from several inputs.
Ask what the business already knows
Ask "what was OEE on line 3 last month?" in plain language and get the answer with the SQL and the records behind it. Nobody hand-builds a semantic layer first or writes a query for each question.
Make the plant's unwritten rules usable
The rules that decide whether a figure is right often exist only in people's heads: which stops count as planned, or which cycle time is the real standard. Antcluster proposes these from the data and from the SQL your team already trusts. Once your engineers approve them, every later answer uses them. Rules such as "OEE can't exceed 100%" are checked before an answer goes out, and a check can pass a finding, flag it or withhold it.
Find what nobody thought to check
Once the data is connected, you can investigate questions nobody had asked, such as whether one product's cycle-time standard has drifted away from what the line achieves. Antcluster returns these as findings with evidence, for your engineers to confirm.
Why this is possible now
Software teams have watched agent harnesses like Claude Code change what a small team attempts, porting an entire console game to PC, say. A big part of that is the harness around the model, which gives the agent context and tools, and lets tests tell it when it's wrong. Code has that structure built in.
Plant data doesn't. A database knows a column holds a number of seconds. It doesn't know whether that number is the agreed standard or one somebody typed in years ago. When an agent has the plant's meanings and rules to check against, it can investigate the numbers instead of repeating them. The result is less effort spent working out what the data means before every question, and more spent following the answer. For the data team it frees time for the analysis that never got scheduled. For operations and finance leaders, at a single site or across a group, it means questioning a figure directly and catching problems before they reach a board pack.
It keeps up as the plant changes
The database, the agent and the plant's rules move together. Each investigation can leave behind an approved definition or a corrected join, and the next question starts from there. The ontology underneath is written in OWL 2 and expands itself as new lines and approved findings arrive, with an engineer reviewing what changes. A question your team has settled, like monthly OEE, is computed the same way every time. A new question comes back with its assumptions listed.
Check the OEE behind your own dashboard
Connect the plant database read-only, inside your network if you prefer, and tell us which figure you want checked. We'll show you how it's computed today, what Antcluster gets, and the SQL and records behind both.
Questions about OEE
What is a good OEE score? It depends on the process and on how losses are defined, so compare a line against its own history first. A published target only means something if your definition matches the one behind it.
Can OEE be more than 100%? No. An OEE above 100% means an input is wrong, usually an ideal cycle time set slower than the machine really runs, or parts counted twice.
Should OEE use ideal or actual cycle time? Standard OEE uses ideal cycle time: the fastest rate the machine can reliably sustain. That makes the standard itself the most important input to check. If the line regularly beats its "ideal", the standard is wrong.
What's the difference between OEE and TEEP? OEE measures performance against planned production time. TEEP (total effective equipment performance) measures it against all calendar time, so it also shows how much of the week the machine isn't scheduled at all.
How do I calculate OEE in Excel? Put planned time, downtime, ideal cycle time, total parts and good parts in five cells. Availability is (planned − downtime) ÷ planned, performance is (ideal cycle time × total parts) ÷ (planned − downtime), quality is good ÷ total, and OEE is the product of the three. Keep cycle time and production time in the same unit.