Machine Status Definitions for CNC Downtime Tracking

Machine Status Definitions (Running, Idle, Stopped, Faulted)

If two shifts can watch the same machine for the same 30 minutes and log two different “statuses,” your downtime data isn’t just noisy—it’s steering decisions in the wrong direction. In a 10–50 machine CNC shop, status labels become the language of accountability: who responds, what gets escalated, and what the morning meeting spends time debating.

The fix isn’t more reports. It’s definition discipline: running vs idle vs stopped vs faulted, written in terms operators can apply and supervisors can enforce across a mixed fleet and multiple shifts. Once those states are consistent, downtime tracking becomes comparable—and “hidden time loss” shows up clearly enough to recover capacity before you consider more machines or more overtime.

TL;DR — Machine Status Definitions

• Status labels are decision labels: each state implies a different owner and next action.

• Define “running” as cycle-active time, not “spindle on” or “coolant on.”

• Idle is “capable of running, not cycling”—often where the most recoverable time hides.

• Stopped is deliberate or process-driven non-running that won’t resume without a deliberate start.

• Faulted requires an alarm/fault condition that blocks normal operation and needs clearance.

• Write rulings for edge cases (warmup, feed hold, door interlocks) so shifts classify events the same way.

• Use a simple audit: sample a handful of events weekly and correct drift before it corrupts trends.

Key takeaway Downtime visibility doesn’t start with dashboards—it starts with state definitions that match real machine behavior. When “idle,” “stopped,” and “faulted” are applied consistently across shifts, you can separate operator-controlled pauses from schedule/material constraints and true alarms, exposing utilization leakage you can recover before spending on new capacity.

Why machine status definitions are the foundation of downtime analysis

A machine “status” isn’t a neutral label. It’s a decision label. When a machine is marked idle, that typically points to an operator workflow, a handoff, or a small stoppage that can often be reduced with standards and supervision. When it’s marked faulted, you’ve signaled a maintenance path and a different escalation. When it’s marked stopped, you’re usually saying the machine is intentionally down for a reason that won’t resolve itself without a deliberate restart (setup, inspection, waiting on material, scheduling).

Inconsistent definitions create three recurring problems in CNC job shops:

• Artificial downtime: the same condition gets logged differently, inflating “downtime” on one shift and deflating it on another.

• Hidden losses: misclassified idle time (often logged as running) masks where capacity is leaking.

• Slow meetings: supervisors spend time debating “what the data means” instead of acting on it.

This is why definition work comes before any deeper analysis. Once the state is consistent, you can layer in reason codes (why it stopped) without arguing about the basic question of whether it was running in the first place. If you’re building a downtime program, treat state definitions as the prerequisite vocabulary for machine downtime tracking.

Core machine states: running, idle, stopped, faulted (plain-language definitions)

The goal is to define each state using observable conditions (signals, alarms, cycle activity), not opinions (“it looked like it was working”). These definitions are written to be enforceable on the floor—even across a mixed fleet where some machines provide richer signals than others.

Running

Definition: The machine is actively executing a program cycle (cycle start engaged and the control is in a cycle-active condition). “Running” should be tied to cycle activity—not spindle on, not coolant on, and not “program loaded.”

Observable criteria: cycle active signal (when available), feed in motion under program control, cycle timer advancing, or a defined “in-cycle” state on the control. If your monitoring approach can’t read cycle-active directly, define the proxy you will use and apply it consistently.

Idle

Definition: The machine is capable of running but is not currently cycling. Think of idle as “ready, waiting.” This is often the highest-leakage state because it includes short pauses, extended waits, and slow restarts that don’t look like “downtime” unless you define them that way.

Observable criteria: no cycle active, no blocking alarm present, control powered and available. The machine may have a program loaded, doors open/closed, spindle stopped, or even auxiliary systems on—none of that overrides the “not cycling but able” rule.

Stopped

Definition: The machine is intentionally not running and is not expected to resume without a deliberate start or a deliberate change in conditions. This includes planned or operational stops such as setups, first-article inspection, waiting on a forklift/material move, scheduling gaps, or end-of-shift policies where the machine is purposely parked.

Observable criteria: no cycle active, no alarm blocking operation, and the shop’s policy says the current condition is a “not running by intent” condition (e.g., setup mode, job complete and queued, planned break classification).

Faulted

Definition: The machine is unable to run due to an alarm/fault condition that blocks normal operation and requires intervention/clearance (operator action, maintenance action, or both).

Observable criteria: active alarm state, fault code present, interlock preventing cycle start, control in alarm. Keep this definition strict; otherwise faulted becomes a junk drawer for any stop the team doesn’t want to own.

If you’re aligning these definitions with automated collection, it helps to understand what data sources and signals different machine monitoring systems can (and can’t) reliably capture—especially across older controls.

Running vs idle: the most common source of hidden capacity loss

In many shops, “running” quietly turns into “anything that looks busy.” That’s how idle time disappears inside run time—especially on unattended or lightly attended machines where coolant might be on, the program might be loaded, and the operator might be nearby, but the machine is not cycling.

Rule of thumb: running is cycle-active time. Everything else that’s not blocked by an alarm is idle (unless your shop policy explicitly calls it stopped). This simple rule keeps “spindle on” ambiguity from corrupting utilization.

Required scenario: Night shift leaves a machine with the program loaded and coolant on but no cycle running; day shift calls it “running” while night shift calls it “idle,” creating a false shift performance gap. Under the definitions above, that condition is idle (capable of running, not cycling). The decision trigger is to clarify the handoff expectation: is night shift required to restart the cycle, or is it acceptable to park the machine in idle for day shift? If it stays mislabeled as running, you’ll “prove” the night shift ran more than it actually did and miss the real loss mechanism (slow restart/handoff discipline).

Common gray areas your policy should name explicitly:

• Warmup cycles: Observed condition: machine executing a warmup routine. Correct state: running (it is cycle-active). Decision trigger: schedule warmup inside planned start-up or treat it as a standard prerequisite. Misclassification risk: calling it idle makes it look like operator delay; calling it stopped can hide the real capacity cost of start-up routines.

• Probing cycles / in-process gauging: Observed condition: machine running a probing subprogram. Correct state: running. Decision trigger: validate whether probing is required or can be optimized. Misclassification risk: labeling as idle makes inspection time vanish into “operator delay” debates.

• Feed hold / single-block: Observed condition: operator pauses motion to verify, clear chips, or check a feature. Correct state: depends on your micro-stop rule (below). Decision trigger: standardize when to pause and what must be prepared before cycle start. Misclassification risk: if every short hold becomes idle, you’ll overstate “idle leakage”; if every hold stays running, you’ll never see repeated hesitation patterns.

• Micro-stop policy: Pick a consistent threshold for brief interruptions so your data doesn’t oscillate between running and idle due to momentary pauses. For example, you might treat interruptions under a small threshold (e.g., under 10–60 seconds) as a continuation of running, and longer interruptions as idle. The exact threshold matters less than consistency across machines and shifts.

When idle is defined cleanly, it becomes a practical capacity lever. That’s the core purpose of machine utilization tracking software: not more charts, but fewer “unknown” gaps between cycles that add up across a multi-shift week.

Stopped vs faulted: separating operational pauses from true alarms

The stopped vs faulted split is where accountability gets distorted. If everything gets labeled faulted, maintenance becomes the default owner for problems that are actually scheduling, material flow, or standard work. If true alarms get labeled stopped, you’ll under-escalate issues that are blocking production and need fast intervention.

Faulted requires a blocking alarm. If the machine cannot resume normal operation until an alarm/interlock is cleared, that’s faulted. Stopped is deliberate/process-driven. If the machine is not cycling because the process or plan says it’s not cycling, and there is no blocking alarm, that’s stopped (or idle, depending on whether it’s “ready, waiting” vs “parked by intent” per your policy).

Required scenario: A machine is in alarm (door interlock / overtravel) but the operator resets it quickly; some logs mark it as “stopped” while others mark it “faulted,” skewing maintenance vs operations accountability. Observed condition: active alarm that blocks cycle start. Correct state: faulted for the duration of the alarm. Decision trigger: route short, repeatable interlocks to training/standard work; route persistent alarms to maintenance. What goes wrong if misclassified: if logged as stopped, the alarm pattern disappears into generic downtime and you don’t see recurring interlocks that could be eliminated with clear procedures or guarding checks.

Edge cases to rule on in writing:

• E-stop pressed: Observed condition: E-stop engaged. Correct state: faulted (machine is in a safety stop requiring reset). Decision trigger: investigate the cause (safety event, crash prevention, training). Misclassification risk: calling it stopped can normalize safety-related interruptions.

• Door open interlock: Observed condition: door opened stops cycle / prevents restart. Correct state: faulted only if the control indicates a blocking interlock/alarm state; otherwise apply your idle rule if it’s simply “not cycling but ready once closed.” Decision trigger: standardize safe access moments (e.g., chip clearing intervals). Misclassification risk: inconsistent labeling creates false maintenance load.

• Tool break detection event: Observed condition: machine stops and requires acknowledgement/reset. Correct state: faulted during the blocking condition. Decision trigger: decide whether the response is maintenance, tooling, or process. Misclassification risk: labeling as stopped blurs true interruptions that need fast response to protect delivery dates.

State transitions and edge cases: write the rules your shop actually argues about

Most definition breakdowns don’t happen in the middle of a clear event (“machine is obviously running”). They happen at transitions: cycle ends, an alarm clears, the operator walks away, the shift ends, or the schedule changes. If you don’t write timestamp rules, two people will start and end the same event at different moments, and you’ll double count or misattribute time.

Use simple “start/end” rules that supervisors can defend:

• Alarm clears but cycle not restarted: faulted ends at alarm clear; if the machine is capable of running but not cycling, it becomes idle. This prevents “faulted” from swallowing post-alarm hesitation time.

• Cycle complete but operator doesn’t unload/reload: running ends at cycle complete; the next state is idle (ready, waiting) unless your shop declares a deliberate stop (stopped) for inspection or scheduled queueing.

• Planned breaks, meetings, end-of-shift: pick a policy and stick to it. Many shops classify these as stopped (deliberate non-running) to avoid punishing operators for planned events; others keep them idle if the expectation is “machine can run if attended.” Either can work—what fails is mixing policies by shift.

Required scenario: Material shortage causes the operator to stop the cycle and wait; depending on definition, it becomes idle time (operator-controlled) or stopped time (schedule/material-controlled), changing what the morning meeting prioritizes. Observed condition: no cycle active, no blocking alarm, and the constraint is upstream material flow. Correct state (recommended policy): stopped if your shop treats material availability as a scheduling/material control issue; idle only if the expectation is that the operator can resolve it immediately (e.g., pull from a nearby rack with standard process). Decision trigger: if it’s stopped, escalate to scheduling/material handling; if it’s idle, address operator readiness and local replenishment standards. Misclassification turns a material system problem into an “operator utilization” argument—or hides operator-driven delays inside “materials.”

Keep an “edge-case appendix” short (5–10 rulings) and update it only when you see repeated disputes. The intent is to stop daily re-litigation, not to create bureaucracy.

How consistent definitions improve downtime tracking (what changes in your reports)

When your shop applies the same state definitions on every shift, reports change in ways that matter operationally:

• Comparability: a “faulted” event on night shift means the same thing as “faulted” on day shift, so shift-to-shift differences reflect reality, not labeling habits.

• Accuracy: idle doesn’t hide inside running, and faulted doesn’t become a catch-all for “machine not making parts.”

• Decision speed: the team spends less time translating logs and more time assigning the next action and owner.

Here’s a simple 30-minute illustrative window showing how inconsistent definitions change conclusions (arithmetic only, no benchmarks):

Observed Condition (30 Minutes)	Consistent Classification	Inconsistent Alternative
18 minutes cycling, 10 minutes waiting with program loaded (no cycle), 2 minutes in a blocking alarm that is cleared	18 running 10 idle 2 faulted	28 running (counts “program loaded” as running) 2 stopped (counts alarm as stopped)

In the consistent version, the decision is obvious: address the 10 minutes of idle (restart/handoff/material-at-machine readiness) and treat the 2-minute alarm as a fault pattern to be prevented. In the inconsistent version, the report suggests everything was “mostly running,” and the alarm looks like an ordinary stop—so neither problem gets owned.

Where to stop: states tell you what the machine was doing. They don’t explain why. That’s the role of downtime reasons, which should be applied after the state is correct. In practice, many shops pair state discipline with a tight daily review and clear escalation paths—especially once they move beyond manual notes toward more automated collection and interpretation.

If you use automated tracking, interpreting repeated patterns across many machines can still take time. Tools like an AI Production Assistant can help summarize clusters of similar events, but the summaries are only as reliable as the underlying state definitions.

Implementing machine status definitions in a 10–50 machine, multi-shift shop

The implementation mistake is trying to make definitions perfect on day one. Your goal is to make them stable and enforceable—then refine the edge cases your shop actually encounters. A pragmatic rollout can be done without creating a corporate IT project.

• Start with a one-page sheet: define running/idle/stopped/faulted in plain language plus observable criteria. Add 5–10 edge-case rulings (warmup, feed hold, alarm cleared/no restart, end-of-shift).

• Align supervisors across shifts first: if leads disagree, operators will freestyle. Run through your three most common disputes and force a single ruling.

• Train with examples, not definitions: show the exact conditions operators recognize (program loaded/no cycle, door interlock, material wait) and ask, “What state is it?” until answers are consistent.

• Audit weekly: sample 10 events across shifts and machines. Check whether classification matches policy and correct drift early.

• Control the document: keep a revision history so definitions don’t “evolve by rumor.” When you change a ruling, communicate it as a revision, not a suggestion.

• Escalation rule: update definitions only when the same disagreement repeats; otherwise enforce the current policy. This prevents endless tweaks that destroy comparability.

As you move from manual logs to automated tracking, plan for two implementation realities: (1) older machines may require different signal proxies for “cycle active,” and (2) you’ll want a simple way to align expectations without adding overhead. If you’re gauging rollout effort and ongoing costs, review how packaging typically works on the pricing side—then sanity-check whether your definition sheet can be enforced with your current supervision structure.

If you want to pressure-test your current state definitions quickly, a good diagnostic is to pick one pacer machine and ask two shifts to classify the same set of edge cases in writing. If the answers differ, your “downtime” totals will differ—even when the machine behavior didn’t.

When you’re ready, the next step is to validate definitions against actual machine signals across a representative mix of controls and shifts, then confirm your team agrees on what gets escalated. If that’s the stage you’re in, you can schedule a demo to walk through your states, edge cases, and how you want events classified before you standardize the policy shop-wide.