How to Calculate Machine Availability in a CNC Shop

How to Calculate Machine Availability in a CNC Shop

Most CNC job shops already have an availability number. It lives in the ERP, it gets reviewed in the weekly production meeting, and it is used to model capacity for new contracts. The problem is not that the number is missing — it is that the number is frequently wrong in a specific, predictable direction: it overstates how much productive time the machine actually had.

ERP systems capture what operators log. They do not observe machine state. That distinction matters more than most shops realize, because the downtime that does not get logged — the between-job idle, the extended tool change, the informal quality hold — does not disappear from the shop floor. It disappears from the calculation. The result is an availability figure that reflects scheduling intent rather than operational reality, and a capacity model built on a number that has never been verified against what the machines were actually doing.

This article walks through the correct method for calculating machine availability in a CNC job shop — including a side-by-side comparison that shows exactly how much the ERP-based figure and the machine-state-based figure can diverge, and what that gap means for quoting and capacity decisions.

TL;DR — How to Calculate Machine Availability in a CNC Shop

• Availability measures the share of planned production time a machine was capable of running — not whether it produced good parts.

• The correct denominator is planned production time, not calendar time or theoretical capacity.

• ERP-reported availability reflects logged downtime only — unlogged stops inflate the figure by a predictable margin.

• Machine-state data captures spindle-off periods that operators do not enter, closing the gap between scheduled and actual uptime.

• A single VMC running two shifts can carry a 9.5-hour weekly blind spot when availability is calculated from ERP alone.

• Inflated availability figures create quoting risk — capacity models built on them overstate what the shop can actually deliver.

• Availability should be reviewed at the shift level, not just weekly, to surface patterns that rollups conceal.

Key takeaway

Availability calculated from ERP scheduled hours is a planning number, not an operational one. The gap between what ERP reports and what machine-state evidence shows is not random — it follows consistent patterns tied to shift transitions, job changeovers, and operator logging behavior. Shops that close this gap calculate availability against a denominator they can defend, and build capacity models that reflect what their machines are actually capable of delivering.

What Machine Availability Actually Measures — and What It Does Not

Availability has a precise meaning that is easy to blur in daily shop conversation. It measures the proportion of planned production time during which a machine was capable of running — not whether it was cutting, not whether it produced conforming parts, and not whether it was running at full speed. Those distinctions belong to other OEE components. Availability answers one question: of the time we planned to produce, how much of it was the machine actually available to run?

The correct denominator is planned production time — the hours a machine was scheduled to be in production during a given period. Total calendar time is not the right denominator. Neither is theoretical maximum capacity. Using either of those inflates the denominator and produces an availability figure that understates actual performance. Planned production time is the boundary within which downtime is measured.

Availability is one input into the broader OEE composite, but it can and should be tracked independently in shops where downtime categorization is the primary measurement problem. If a shop does not yet have reliable availability data, calculating a full OEE score adds precision to an already uncertain foundation. Availability is the right place to start. For a broader look at how machine monitoring systems support this kind of measurement, that context is worth reviewing separately.

One boundary worth stating clearly: availability ends where performance efficiency begins. A machine that was available but running at reduced feed rates, or cycling through micro-stops without going fully offline, is an availability-adjacent problem that belongs to the performance component of OEE. This article stays within the availability boundary — downtime that removes the machine from planned production entirely.

The Standard Availability Formula and How to Apply It in a Job Shop

The formula is straightforward:

Availability = (Planned Production Time − Downtime) ÷ Planned Production Time × 100

In job shop terms: planned production time is the total hours a machine was scheduled to run during the measurement period, excluding planned maintenance windows and scheduled breaks that were built into the shift structure from the start. Downtime is any period during which the machine was not capable of running due to an unplanned stop — a breakdown, a tooling failure, a quality hold, or any other event that interrupted production.

Here is a clean baseline example. A 3-axis VMC runs two 10-hour shifts, five days per week. Planned production time for the week is 100 hours. During the week, two downtime events were logged in ERP: a spindle fault that took the machine offline for 8 hours on Tuesday, and a tooling replacement that caused a 5-hour stop on Thursday. Total logged downtime: 13 hours.

Availability = (100 − 13) ÷ 100 × 100 = 87%

That number is arithmetically correct given the inputs. The question is whether the inputs are complete. The formula is only as reliable as the downtime data that feeds it — and in most job shops, that data has gaps.

Why ERP-Reported Time Produces a Different Availability Number

ERP systems capture what was planned and what operators chose to log. They do not observe machine state. This is not a design flaw — ERP was built for job costing, scheduling, and order management. Real-time machine-state monitoring was never part of its scope. But that structural limitation has a direct consequence for availability calculations: any downtime that an operator does not enter into ERP does not reduce the reported availability figure.

The stops that go unlogged are not random. They follow predictable patterns. Between-job idle — the time a machine sits after one job completes and before the next setup begins — is rarely entered as a downtime event because no one considers it a "breakdown." Extended tool changes that run longer than standard are absorbed into the job time rather than flagged as a stop. Informal quality holds, where an operator pauses the machine to check a dimension or wait for an inspector, often go unrecorded entirely. Shift handoff gaps, where the machine sits idle while the incoming operator gets briefed, are invisible to ERP.

The result is an availability figure that reflects scheduling intent rather than what the machine actually did. This is not an indictment of ERP — it is a recognition that ERP was not designed to close this gap. Machine downtime tracking that relies on machine-state signals rather than operator entry captures these events automatically, which is why the two methods consistently produce different numbers.

Side-by-Side Calculation: ERP Time vs. Machine-State Evidence

Return to the VMC running two 10-hour shifts, five days per week. ERP shows 100 scheduled hours for the week. Two downtime events were logged: 8 hours for the spindle fault, 5 hours for the tooling replacement. ERP-based availability: 87%.

Now introduce machine-state log data for the same week. The controller-level records show spindle-off periods during scheduled production that were not captured in ERP. Specifically:

• 3.5 hours of between-job idle spread across Monday, Wednesday, and Friday — the machine sat ready but unloaded while the next job was being staged.

• 2.5 hours of extended tool change time on two separate setups that ran significantly longer than standard, neither of which was logged as a downtime event.

• 3.5 hours from a mid-shift quality hold on Thursday afternoon, during which the machine was stopped while a supervisor reviewed a dimensional issue. The hold was resolved informally and never entered into ERP.

Total additional spindle-off time: 9.5 hours. None of it appeared in ERP.

Recalculated availability using machine-state evidence:

(100 − 13 − 9.5) ÷ 100 × 100 = 77.5%

The difference is 9.5 percentage points. A shop reviewing its weekly ERP report sees a machine performing at 87% availability. The machine-state record shows 77.5%. That 9.5-hour gap per machine per week is not a rounding error — it is a structural blind spot in the measurement method. For a shop running multiple VMCs across two shifts, the cumulative effect on capacity visibility is significant. Machine utilization tracking software that reads machine-state directly closes this gap without depending on operator entry.

What the Gap Means for Capacity Planning and Quoting

Consider a shop preparing to quote a contract that requires adding a third shift. The owner pulls current availability figures from ERP — the machines are showing 85–88% across the floor — and builds a capacity model based on those numbers. The model says the shop can absorb the new volume. The quote goes out. The contract is won.

What the model did not account for is that the ERP figures are inflated by 8–12 percentage points due to unlogged idle time. The machines are not running at 87% — they are running closer to 77%. The capacity that looked available on paper does not exist on the shop floor. That discrepancy does not surface during the quoting process. It surfaces after the contract starts, as delivery dates slip and overtime costs accumulate to cover the gap.

Availability accuracy is a quoting input, not just a performance metric. Shops that calculate availability from machine-state data can model capacity with a tighter confidence interval — they know what their machines are actually delivering, not what the schedule assumed they would deliver. That distinction changes the risk profile of every contract decision.

How to Improve the Accuracy of Your Availability Calculation

Improving availability accuracy starts with two separate problems: the denominator and the numerator.

The denominator problem is definitional. Planned production time must be defined consistently across shifts and machines. If one shift supervisor counts a 30-minute startup period as planned production time and another does not, the availability figures are not comparable. Establish a single definition and apply it uniformly before drawing any conclusions from the numbers.

The numerator problem is behavioral. Operators do not log every stop — not because they are negligent, but because the friction of entering a short idle event into ERP is higher than the perceived value of doing so. The stops that go unlogged are real; they just do not appear in the calculation. Machine-state data — whether sourced from a controller, a current sensor, or a dedicated monitoring device — captures these events automatically, removing the dependency on operator entry for downtime completeness.

A practical starting point: select one machine and one shift, run both the ERP-based and machine-state-based calculations in parallel for two to four weeks, and compare the results. The gap between the two figures will tell you how much your current availability number is overstating actual performance. Once the method is validated on one asset, it scales to the rest of the floor without changing the underlying formula.

Availability figures should also be reviewed at the shift level, not just in weekly rollups. A machine that averages 80% availability across the week may be running at 90% on first shift and 70% on second. That pattern is invisible in a weekly summary and actionable at the shift level. Weekly rollups smooth out the variation that contains the most useful operational information.

Using Availability as an Operational Signal, Not Just a Report

Availability calculated after the fact tells you what happened. Availability tracked in near-real-time tells you what is happening — and gives operations managers the ability to respond before a pattern becomes a delivery problem.

A machine running at 77% availability when the shop is quoting at 87% is not just a reporting discrepancy — it is a capacity signal. The 10-point gap represents recoverable time that is currently being absorbed invisibly into the production schedule. Identifying which machine, which shift, and which event type is responsible for that gap is the first step toward recovering it. An AI Production Assistant can help interpret machine-state patterns at this level of granularity, surfacing the specific contributors to availability loss rather than leaving the analysis to manual review.

Availability trends over time reveal whether downtime is improving, holding steady, or drifting in the wrong direction — none of which is visible in a single weekly report. A shop that tracks availability by machine and by shift over rolling periods can distinguish between a machine that had a bad week and a machine that is consistently underperforming. That distinction changes how the operations manager responds.

The goal is not a perfect availability number. It is a reliable one — a figure the team can act on, defend in a quoting conversation, and use to make capital and staffing decisions with confidence. That reliability requires a measurement method grounded in what the machines are actually doing, not what the schedule assumed they would do.

If your current availability figures come from ERP alone, the calculation in this article shows exactly where the gap originates and how large it can be. Shops running 10 to 50 machines across multiple shifts are closing that gap without replacing their ERP or adding headcount — by connecting machine-state data directly to the availability calculation. Review pricing to understand what that looks like at your scale, or schedule a demo to see how the calculation compares against your current numbers.