OEE availability: how to calculate it from your downtime data

Availability is the first of the three numbers that make up OEE, and it is the one built entirely from your downtime data. Performance and quality need cycle-time and scrap records, but availability comes straight off the same downtime log you already keep at the machine. Get the log right and the availability number falls out of it. Get the log wrong — or classify it creatively — and you can post an OEE that looks world-class while the machine sits idle half the shift.

This guide shows exactly how availability is calculated, what belongs in the denominator, and the reclassification habits that inflate the number without producing a single extra part.

Where availability sits in OEE

OEE is the product of three factors:

OEE = Availability × Performance × Quality

Because the three multiply, availability caps the other two. A machine that is only available 70% of its scheduled time cannot post an OEE above 70%, no matter how fast or clean it runs. That is why availability is where most improvement programs start, and why your downtime log is the most valuable data you already own.

Availability — did the machine run when it was supposed to? This is a downtime question.
Performance — when it ran, did it run at its rated speed? This is a cycle-time question.
Quality — of what it produced, how much was good? This is a scrap question.

The availability formula

Availability has a simple definition:

Availability = Run Time ÷ Planned Production Time

where

Run Time = Planned Production Time − Downtime

Two terms decide everything, and both are where people go wrong.

Planned Production Time is the time you intended to run the machine. Start from your total shift time, then subtract schedule loss — the hours you never planned to produce in the first place: unstaffed shifts, weekends you were closed, and time with no orders on the machine. What is left is the clock the machine is accountable to.

Downtime is every minute inside Planned Production Time that the machine was not running. In classic OEE this includes both unplanned stops (breakdowns, tooling failures, material starvation) and planned stops that happen during a scheduled shift — most importantly changeovers and setups. This last point is where honest calculations and flattering ones diverge.

What counts as planned production time

The single most common way to break an availability number is to move an item between "schedule loss" (time where the machine was never scheduled to run) and "downtime" (your true lost time). The rule that keeps you honest:

A changeover is the classic trap. It is planned, so it feels like it should not count against you. But it happened during a scheduled production window, so in standard OEE it is availability loss. Excluding it does not make your line more available; it just hides your single biggest improvement opportunity behind a definition.

If the machine was never scheduled to run — no shift, no crew, no order — that time is schedule loss and stays out of Planned Production Time entirely.
If the machine was scheduled to run but did not — for any reason, including a planned changeover — that time is downtime and counts against availability.

A worked example: 4 weeks on a CNC machining center

Here is a month of downtime data from a CNC machining center running two eight-hour shifts, five days a week. That is 16 productive hours a day, so Planned Production Time is 16 × 5 × 4 = 320 hours. Breaks and unstaffed hours are already excluded as schedule loss. Operators logged every stop over five minutes against a fixed code list, closing each event when the spindle restarted.

Total downtime is 2,688 minutes, or 44.8 hours. Now apply the formula:

That 86.0% is the honest number, and it already tells you where to look: setup accounts for 1,190 of the 2,688 downtime minutes — 44% of all lost time on its own. Before you touch a single breakdown, the availability math is pointing you at a changeover-reduction (SMED) study.

To finish the OEE picture, suppose the machine ran at 95% of rated cycle time when it was running (Performance) and produced 98% good parts (Quality):

OEE = 0.860 × 0.95 × 0.98 = 80.0%

An OEE of 80% sits just under the 85% figure often cited as world-class. And availability is the factor dragging it down — exactly the story the downtime log tells.

Planned Production Time = 320 h
Downtime = 44.8 h
Run Time = 320 − 44.8 = 275.2 h
Availability = 275.2 ÷ 320 = 86.0%

How the number gets inflated

Watch what happens if you decide setup "shouldn't count" and quietly move those 1,190 minutes out of both downtime and Planned Production Time:

Availability jumped from 86.0% to 91.7%, and OEE would climb from 80.0% to 85.4% — suddenly "world-class." But look at Run Time: still 275.2 hours. The machine did not make one extra part. All that changed was the classification. This is the most common way a plant reports a great OEE that nobody on the floor believes.

A few more habits that inflate availability the same way:

The fix for all of these is the same: a fixed reason-code list, actual start and stop times, and a planned-versus-unplanned split you do not renegotiate to protect the number.

New Planned Production Time = 320 − 19.83 = 300.17 h
New Downtime = 44.8 − 19.83 = 24.97 h
New Run Time = 300.17 − 24.97 = 275.2 h
Availability = 275.2 ÷ 300.17 = 91.7%
Reclassifying unplanned stops as planned. A breakdown relabeled "planned maintenance" after the fact protects the number and buries the reliability signal.
Rounding downtime down. Estimated durations drift toward the low round number. Fifteen minutes logged as ten, every time, adds up to phantom availability.
Dropping short stops. Minor stops under your logging threshold are real availability loss. They belong in performance loss if you track speed, but if you simply ignore them they vanish from OEE entirely.
Using calendar time as the denominator. Dividing Run Time by all 672 hours in four weeks instead of the 320 scheduled hours measures a different metric (TEEP, total effective equipment performance), not availability. Mixing them up usually understates the problem and confuses the meeting.

Availability tells you the ceiling, downtime tells you the fix

Availability is a scoreboard; it does not tell you what to do. The number that came in at 86.0% only becomes useful when you break it back down by reason code — which is a downtime Pareto analysis. The Pareto is what turns "we lost 44.8 hours" into "setup is 44% of it, so run a SMED study on the top two jobs." Availability sets the ceiling on your OEE; the downtime breakdown underneath it is where you actually raise the ceiling.

That is why the two metrics live together. Track availability to know how much room you have, and keep the reason-coded downtime log so you know which stop to attack first.

Where HelpFab fits

The availability calculation is arithmetic — the hard part is a clean, honest downtime log to run it on. In HelpFab's Issues and downtime tracking, operators log each stop against a machine from a phone or tablet using your own configurable issue types, and the Issue Reports page turns those logs into Pareto and trend views over any date range. Because every stop carries a start time, a stop time, and a code from a fixed pick-list, the raw material for an availability number is already structured — no cleanup, no renegotiating what counts. Keep the planned/unplanned split in your issue types and the same log answers both the availability question and the "what do we fix first" question.

If you are still building the log itself — deciding what counts, what threshold to set, and who records each stop — start with how to track machine downtime. Get the log right and availability, and the OEE built on top of it, become numbers you can defend in any meeting.

Latest articles

Maintenance log vs downtime log — Maintenance log vs downtime log - what each one captures, why a plant needs both, and how a single breakdown links them to give you MTTR and MTBF.
Choosing a downtime tracking app for a small manufacturer — What a small shop should look for in a downtime tracking app: phone logging, configurable reason codes, and reports you can read without an ERP.
How to reduce unplanned downtime in manufacturing — A track-first playbook to reduce unplanned downtime - log every stop, Pareto the causes, then attack the vital few with PM and root-cause fixes.
How to calculate the cost of unplanned downtime — A cost-per-hour formula for unplanned downtime, with a worked molding-cell example covering labor, scrap, lost margin, and overhead.
A free downtime tracking Excel template (and how to actually use it) — A free Excel downtime log template — the columns, a reason-code list, and the pivot that turns raw stops into a Pareto, plus when to move off it.
How to build a downtime Pareto analysis — Build a downtime Pareto step by step with a worked stamping-line example that finds the few causes driving most of your lost minutes.
A practical machine downtime reason code list — A starter taxonomy of machine downtime reason codes — planned vs unplanned, with real fault-code examples and rules that keep operators logging honestly.
Downtime tracking spreadsheet vs software — When an Excel downtime tracker is enough and when it quietly breaks — a shift-by-shift comparison for small manufacturers, with a real cost example.
How to track machine downtime — Move from a paper downtime log to structured tracking: reason codes, who logs what, and the three reports that actually change decisions.