OEE Calculation Example for CNC Job Shops

OEE Calculation Example (CNC Job Shop Numbers You Can Copy)

You can ship the right number of parts this week and still be quietly losing capacity every shift. In CNC shops, that “phantom time” usually isn’t a single big breakdown—it’s a stack of small stops, waiting on tooling or program tweaks, slow cycles that feel normal, and a handful of scrap pieces that force remake time later.

An OEE calculation example is useful only if the math ties back to what actually happened at the machine: what was planned, what stopped, what ran slower than target, and what didn’t pass. Below is a complete, numbers-first example you can replicate on one VMC, then extend across shifts to pinpoint which loss bucket is stealing capacity today.

TL;DR — OEE calculation example

• Start with one machine and one repeat job; write down planned time, stops, total pieces, and scrap.

• Availability is mostly a downtime log problem (planned breaks vs unplanned stops vs waiting).

• Performance catches “it was running” losses: overrides, conservative programs, extra non-cut time.

• Quality is good pieces divided by total pieces; scrap hits capacity twice (make + remake).

• Small, recurring 5–10 minute issues per shift compound into meaningful weekly spindle hours.

• Compare Day vs Night on the same part to expose different dominant losses (A vs P vs Q).

• Use the result to rank the biggest loss bucket first; don’t chase the lowest percentage.

Key takeaway OEE becomes operational when you can reconcile ERP “it ran” with shop-floor reality: stop time, slow cycles, and scrap patterns that differ by shift. The goal isn’t reporting—it’s exposing utilization leakage fast enough to recover capacity before you assume you need overtime or another machine.

The OEE calculation example (numbers first, then meaning)

Scenario 1: A 2-shift CNC cell with one VMC running a repeat job. Output looks “fine,” but there are small unplanned stops and some waiting on tools/program revisions that add up. We’ll calculate OEE for one shift first, then convert it to weekly lost spindle hours and equivalent parts.

Assumptions (one 8-hour shift): Shift length = 480 minutes Planned breaks/meeting = 40 minutes (planned downtime) Ideal cycle time (proven run) = 2.0 minutes/part Total pieces produced = 190 Scrap pieces = 6 Unplanned downtime minutes (stops + waiting) = 55 minutes

Step 1: Planned Production Time (PPT) PPT = Shift length − Planned breaks PPT = 480 − 40 = 440 minutes

Step 2: Run Time Run Time = Planned Production Time − Unplanned downtime Run Time = 440 − 55 = 385 minutes

Availability Availability = Run Time ÷ Planned Production Time Availability = 385 ÷ 440 = 0.875 (87.5%)

Performance Performance = (Ideal cycle time × Total pieces) ÷ Run Time Performance = (2.0 × 190) ÷ 385 = 380 ÷ 385 = 0.987 (98.7%) (This means the cycle pace is close to target during run time—the bigger hit so far is stoppage/waiting time.)

Quality Good pieces = Total − Scrap = 190 − 6 = 184 Quality = Good ÷ Total = 184 ÷ 190 = 0.968 (96.8%)

OEE OEE = Availability × Performance × Quality OEE = 0.875 × 0.987 × 0.968 = 0.836 (83.6%)

Meaning (one sentence): This machine isn’t primarily “slow” in cycle; it’s losing usable capacity today through stop time and a small but real scrap/remake burden—exactly the kind of utilization leakage that compounds across shifts.

Step-by-step: turning a downtime log into Availability

Availability only becomes trustworthy when everyone agrees what time was planned, what time was truly down, and what time is “waiting” that never makes it into ERP notes. You don’t need an exhaustive code list to start—just a minimum set that prevents the most common debates.

Minimum categories for this example: (1) Planned breaks/meetings (planned downtime), (2) Setup/changeover (if it’s inside the shift plan, treat it consistently as planned or unplanned), (3) Unplanned stops (faults, jams, alarms), (4) Waiting (tools, material, program revisions, inspection approval), (5) Unknown/Other (temporary bucket, but keep it small).

Clean subtraction rule: subtract planned time first (breaks), then subtract unplanned losses from the remaining Planned Production Time. That prevents “double counting” breaks as downtime and makes shift-to-shift comparisons fair.

CNC pitfalls that distort Availability: setup creep logged as “running” because the control is powered and the operator is at the machine; waiting on a toolholder, insert, or in-process gage that gets treated as “just part of the job”; and program edits/first-piece approvals that sit outside any downtime note. If those minutes don’t get captured, Availability looks better on paper while the schedule gets tighter in reality.

Consistent start/stop capture matters more than perfect categorization at first. The quickest path is: record when the machine stops producing and when it resumes, then tag the reason with a small set of options. If you’re trying to get stoppage visibility across a mixed fleet, the broader rollout mechanics sit in machine downtime tracking.

Quick check for Availability error sources: missing micro-stops (short pauses that happen repeatedly), an oversized “Other” bucket, and any time labeled “running” where no parts were actually being completed (setup, searching for tools, waiting on approval).

Step-by-step: Performance loss (the ‘it was running’ trap)

Performance is where a lot of job shops get surprised: the spindle is turning and parts are coming off, so it “feels” productive. But small cycle-time penalties—especially on repeat work—become hours of lost capacity over a week.

The calculation is straightforward: compare a repeatable target (ideal cycle time from a proven run) to the actual pace reflected by output during run time. In our first scenario, Performance was high because the cycle pace was close to target once the machine was actually running; the larger issue was stop time/waiting.

Typical CNC causes of Performance loss: feed/speed overrides left conservative after a tough material batch; a “safe” program revision adding extra air-cutting or retracts; probing frequency creeping up; chip management pauses that don’t get counted as downtime because the cycle technically continues; and toolpath choices that add seconds in multiple places.

How seconds become hours (hypothetical example): if a repeat part should run at 2.0 minutes but averages 2.1 minutes, that 0.1 minute (6 seconds) loss repeats every cycle. Across hundreds of cycles per week on two shifts, it can consume multiple hours of capacity even though the machine appears “busy.”

Guardrail: don’t use a nameplate or “best ever” cycle time that nobody can sustain. Use a target from a stable run with known tooling and workholding, then keep it consistent long enough to see whether changes helped.

Decision output: verify overrides at shift start, confirm the current program revision matches the approved baseline, and identify whether non-cut motions (retracts, air moves, probing) increased versus the last “good” run. If you’re scaling this across machines, machine utilization tracking software helps separate true cutting time from “busy but not productive” patterns.

Step-by-step: Quality (why scrap hits capacity twice)

Quality is the simplest math and often the most emotionally charged on the floor. For OEE, keep it consistent: Quality is the share of pieces that meet requirements without needing to be remade.

Quality calculation (from Scenario 1): Quality = Good pieces ÷ Total pieces = 184 ÷ 190 = 96.8%

CNC realities that drive Quality loss: first-article adjustments that take a couple iterations to dial in; tool wear that changes cut behavior late in the run; probing/calibration drift; offset handling differences by operator; and inspection timing that lets a problem run longer than it should. (None of this requires predicting failures—the point is to locate where defects originate and how quickly they’re detected.)

Why scrap hits capacity twice: you spent run time producing a bad part, then you need additional run time to replace it with a good part. Late-process scrap is especially painful because it often arrives after downstream operations are queued or after the schedule has assumed those pieces are done.

Rework counting rule: decide whether reworked pieces count as “good” only after they pass and whether the rework time is tracked separately. The goal is not accounting purity—it’s decision-making consistency so you can see if first-article failures or tool-related scrap is trending up on a shift or job family.

Decision output: tighten when and where you inspect (earlier checks on risky features), standardize tool change/insert policies for repeat jobs, and lock down offset management practices so “good runs” are repeatable across shifts.

Second example: Day vs Night shift—same output, different OEE story

Scenario 2: same part number on Day vs Night shift. Shipped output looks similar, but the loss driver differs. This is where OEE becomes diagnostic: it tells you whether to chase stops, cycle pace, or quality—not just “work harder.”

Assumptions for both shifts: 8 hours (480 minutes) with 40 minutes planned breaks, ideal cycle time 2.0 minutes/part.

Shift	Total Pieces	Scrap	Unplanned Downtime	Availability	Performance	Quality	OEE Score
Day	190	6	55 min	$\frac{440 - 55}{440} = 87.5\%$	$\frac{2 \times 190}{385} = 98.7\%$	$\frac{184}{190} = 96.8\%$	83.6%
Night	188	2	25 min	$\frac{440 - 25}{440} = 94.3\%$	$\frac{2 \times 188}{415} = 90.6\%$	$\frac{186}{188} = 98.9\%$	84.4%

Notice what’s happening: the Night shift has better Availability and Quality (fewer stops, less scrap), yet worse Performance (slower average pace). Output shipped can look similar, but the hidden story is different: Day is getting interrupted; Night is running more continuously but at a reduced rate—often from feed overrides, warm-up routines, conservative “just keep it safe” operation, or operator-to-operator variance.

What to investigate first: Day shift (Availability-dominant loss): staging tools/material earlier, tightening program revision/approval flow, and logging “waiting” explicitly so it doesn’t disappear into anecdotes. Night shift (Performance-dominant loss): standardize start-up/warm-up expectations, verify overrides and cycle targets on repeat work, and confirm the job packet matches the proven baseline (same tools, offsets, probing routine).

Decision speed lens: overrides and work instructions can change within 24–72 hours; tool crib access, program approval delays, and staging discipline may take a bit longer but still move faster than buying another machine to “solve” a capacity problem that’s actually leakage.

If you’re trying to reduce arguments about what happened between shifts, the practical baseline is consistent capture of stops and cycle pace. For a broader overview of approaches, see machine monitoring systems.

What to do with your result: convert OEE into lost hours, parts, and dollars

OEE becomes actionable when you translate it into production terms: minutes you didn’t get, parts you couldn’t make, and dollars you can estimate using your shop’s rate or margin. This is also how you avoid jumping straight to overtime or capital spend before eliminating hidden time loss.

Using Scenario 1 (one shift): Planned Production Time is 440 minutes. OEE is 0.836. One practical way to express “effective productive time” is: Effective productive minutes ≈ OEE × Planned Production Time = 0.836 × 440 ≈ 368 minutes Lost effective minutes ≈ 440 − 368 ≈ 72 minutes per shift (capacity you planned for but didn’t fully convert into good, on-pace output).

Convert lost minutes to lost parts (using ideal cycle time): Equivalent parts not made ≈ Lost minutes ÷ Ideal cycle time = 72 ÷ 2.0 ≈ 36 parts per shift (equivalent capacity, not a guarantee of demand).

Extend to the week (2 shifts): if you run 5 days/week and two shifts, that’s 10 shifts/week. Weekly lost effective time ≈ 72 × 10 = 720 minutes (about 12 hours) of capacity on that one VMC. That’s where “a few minutes here and there” becomes real schedule pressure.

Optional dollars (reader-supplied): multiply weekly lost hours by your internal machine hourly rate or use contribution margin per part. The point isn’t to publish a universal ROI; it’s to make the tradeoff visible: fix leakage first, then decide whether you truly need overtime or another machine.

Prioritization rule: fix the biggest loss bucket first (minutes), not the lowest percentage. If Availability loss is dominated by “waiting on tools/program revisions,” that’s usually a faster recovery than chasing minor cycle optimization.

Minimum action list (start tomorrow)

• Planned production time: what counts as planned breaks/meetings vs no-schedule time.

• Stop time with reason: even a small set (unplanned stop, waiting, setup/changeover).

• Target cycle time for repeat jobs: one baseline number you don’t “move” to fit the story.

Once you’re capturing data consistently, the next bottleneck is interpretation: turning raw stops and cycle variance into a clear “what changed and where do we look.” That’s exactly where an AI Production Assistant can help teams move from logs to action without endless meetings about whose notes are right.

Common mistakes that make OEE useless in job shops (and how to avoid them)

In high-mix environments, OEE can turn into a scorekeeping exercise unless you protect it with a few rules. These are the failure modes that create “ERP says one thing, the floor says another,” and they’re fixable.

• Counting planned time inconsistently: if breaks and meetings get treated differently by shift, Availability comparisons become noise. Set one rule and keep it.

• Using a moving “ideal cycle”: if the target changes whenever the story changes, Performance stops being diagnostic. Use a baseline from a proven run and update it deliberately, not casually.

• Ignoring micro-stops and waiting: these are the classic utilization leakage sources in CNC—tool searches, material staging, program edits, gage/inspection holds. Capture them even if the first pass is rough.

• Comparing unlike jobs/machines without context: don’t weaponize OEE across completely different parts, tolerances, or setups. Use it to find loss drivers within a job family or repeat process.

• Treating OEE as a report card: the win is faster decisions—same-day visibility into why capacity slipped and what to fix first.

If you’re moving from manual sheets/spreadsheets to automated capture, keep the implementation bar practical: consistent stop capture, consistent cycle targets, and shift-level visibility before you try to perfect categories. Cost and rollout questions usually come up right after the first credible OEE baseline—see pricing for the implementation-level framing (without turning this into a feature debate).

If you want to sanity-check your first OEE baseline on a real machine and identify which loss bucket is worth chasing first (Availability vs Performance vs Quality), schedule a demo. Bring one repeat job, one week of shift notes (even imperfect), and your best estimate of ideal cycle time—we’ll help you translate it into a clean, repeatable calculation and an action list you can run within days.