Notify When Machine Stops Running (Email Alerts)

Notify When a Machine Stops Running (Without Noisy Alerts)

A CNC can stop at 2:13 AM, sit idle through a tool-break alarm, and nobody knows until the next walk-through. Meanwhile the ERP still looks “on schedule” because the traveler moved, the last op was reported, or the part count was updated earlier. That gap—between what the system thinks happened and what the machine is actually doing—is where unplanned idle minutes hide.

If you’re searching “notify when machine stops running,” you’re not looking for another dashboard. You’re looking for a reliable trigger that turns a stop event into a simple workflow: detect the stop, wait long enough to avoid nuisance alerts, notify the right supervisor, and make the message actionable so someone can get the spindle turning again.

TL;DR — notify when machine stops running

• Define “stopped” operationally (cycle stop vs planned pause vs blocked/starved) before you alert.

• Use a minimum-duration threshold (often 2–5 minutes) to filter brief inspections and chip clearing.

• Prefer machine state changes (in-cycle/alarm/feed hold) over end-of-shift reporting for response time.

• Start minimum-viable: one machine, one shift window, one supervisor recipient.

• Design the email for triage: machine, stop time, duration, last job/part, and the next step.

• Add escalation and repeat-suppression so one stop creates one alert chain—not a flood.

• Close the loop: capture acknowledge and restart times, then log a reason code after the fire is out.

Key takeaway If “stopped” isn’t defined with thresholds, schedules, and ownership, your alerts will either spam supervisors or miss the downtime that matters. The goal is operational visibility that exposes ERP-vs-reality gaps, highlights shift-level idle patterns, and recovers capacity by shortening the time between a stop and a response.

What “machine stops running” should mean (so alerts aren’t noisy)

“Stopped” sounds obvious until you try to alert on it. In a CNC shop, a machine can be not cutting for a good reason (setup, inspection, chip clearing) or a bad reason (alarm, tool break, waiting on material). If your system treats every non-cutting moment as an incident, supervisors quickly learn to ignore emails.

Start by separating common states: cycle stop (program not in cycle), power off (intentional shutdown), planned pause (breaks, scheduled setups), and “blocked/starved” behavior (ready to run but waiting on an input like material, fixture, or an operator action). You don’t need a deep taxonomy—just enough to avoid treating normal work as an emergency.

Next, set a minimum stop-duration threshold so micro-stops don’t page people. A practical starting range is 2–5 minutes, then adjust per process. This is how you prevent the day-shift scenario where a machinist pauses to inspect a feature or clear chips and an alert fires even though the stop is expected and brief.

Finally, decide what signal will represent “running” versus “not running.” Some shops use “in cycle.” Others use “part count changed” (especially if cycle signals are limited). Others use a consolidated machine state like “idle.” Whatever you choose, build in planned downtime windows—breaks, shift change, scheduled PM, long setups—so alerts are suppressed when stopping is normal.

If you want the bigger framework for classifying stops after you respond, this is the companion concept behind machine downtime tracking—but the alert itself should stay simple and low-noise.

Inputs you need to trigger an email alert (and what to do if you don’t have them)

Email alerts only work if they’re triggered by shop-floor reality—machine state changes—not by manual updates that arrive 30 minutes later (or at end of shift). Common inputs that can indicate “running” or “stopped” include: cycle running, feed hold, alarm state, part counter, and sometimes spindle state/load.

The reason state-change detection matters is response time. A night shift may have fewer eyes on the floor; if a tool breaks at 2:13 AM and the machine sits in alarm until someone happens to walk by, you lose capacity without noticing. Alerts exist to reduce that “time-to-notice,” not to create prettier reports.

If you don’t have rich signals on a legacy machine, you can still build a workable trigger by using part-count stagnation plus a time threshold. Example: “If part count hasn’t changed for 10–20 minutes during a scheduled run window, notify.” It’s not perfect, but it’s often enough to catch “sitting idle” events that would otherwise be invisible in an ERP until later.

If you’re currently relying on clipboards, whiteboards, or operators to backfill downtime at the end of a run, it’s worth understanding why that breaks down at scale. This overview of manual operations tracking spells out the predictable failure modes: late timestamps, missing context, and “best guess” reason codes—especially across multiple shifts.

Minimum viable approach: start with one machine, one shift window, and one supervisor recipient. Prove your stop definition is trustworthy before rolling it across 20–50 machines and accidentally creating a culture of alert fatigue.

Step-by-step: set up an email alert when a specific machine stops

Here’s a practical configuration path using one CNC as the pilot. The goal is a clear stop event, a threshold that avoids nuisance pings, and recipients who can act fast.

1) Select the machine and name it like your supervisors think

Choose one asset, for example: “HAAS VF-2 — Cell A.” Use the naming convention your leads already use (cell + machine) so the email is instantly recognizable on a phone.

2) Choose the stop condition you can trust

Start simple: “state = not running” or “not in cycle.” If you have alarm state, you can add logic like “not running AND alarm = true” for higher urgency. If signals are limited, use “part count unchanged” as the proxy.

3) Set debounce/threshold to prevent false alarms

A common starter rule is: alert if the machine is stopped continuously for 3 minutes. This directly addresses the day-shift reality: an operator pauses for inspection or chip clearing and returns to cycle quickly; the alert never fires because the stop didn’t persist beyond the debounce window.

4) Define schedules (and exclude planned downtime windows)

Decide when the alert should be “armed.” Example: active during 2nd and 3rd shift; suppressed during shift change and defined break windows. For weekend unattended runs, you may arm a different schedule (e.g., Saturday/Sunday) and apply longer thresholds so you’re not notified for every short pause that self-resolves.

5) Choose recipients and escalation rules

Assign one accountable owner (night supervisor, cell lead, or on-call). Then add a backup recipient if the alert isn’t acknowledged within a set time window. This is how you handle the night-shift scenario: a tool break at 2:13 AM should go to the night supervisor first, then escalate if it sits unacknowledged.

6) Test with a controlled stop and validate timestamps

Do a controlled interruption (pause cycle or trigger a safe stop), then compare: the moment the machine stopped, when the debounce window elapsed, and when the email landed. You’re checking that the alert reflects shop reality—not “computer time,” not late operator reporting, and not an ERP operation completion that happened earlier.

If you’re evaluating tooling to support this workflow across a mixed fleet, keep the scope on event-triggered response rather than general visibility. This overview of machine monitoring systems can help you sanity-check what inputs and alert controls you should expect without getting pulled into a feature checklist.

Worked example: the exact email you want a supervisor to receive

The best alert is the one a supervisor can triage in seconds. If the email forces them to open three systems, interpret raw tags, or guess what action to take, response slows down—and the alert becomes noise.

Section	Field	Details
Email Header	Subject Line	VF-2 Cell A — STOPPED 3+ min (since 2:13 AM)
Email Body	Machine	HAAS VF-2 — Cell A
	Status	Not running (continuous)
	Stop Start	2:13 AM
	Current Duration	6 minutes
	Last Known Job / Part	Op 20 — Part 104 (if available)
	Last State / Alarm	Alarm present (possible tool break) / Feed hold (if available)

Next step: Check the control for alarm message, verify tool condition, confirm door/estop, and restart if safe. If tooling failure, tag the event for tooling follow-up after production is stabilized.

Notice what’s missing: a long list of signals. The email should carry only what helps decide “Who goes to the machine, and what are they looking for?” If you want help interpreting recurring patterns without turning every stop into a meeting, tools like an AI Production Assistant can be useful for summarizing event context and recurring causes—after you’ve made the alert itself reliable.

Prevent alert fatigue: rules that keep supervisors from ignoring emails

If supervisors get five emails for one stop event, or if they get notified every time an operator wipes chips off a fixture, emails become background noise. Alert design is about building trust: when the email arrives, it should usually merit attention.

Use tiered thresholds that match how your shop actually responds. For example: notify at 3 minutes, escalate at 10 minutes, and notify management at 30 minutes during unattended windows. This is particularly relevant to weekend unattended runs: the first ping goes to the on-call supervisor, and if it stays stopped past a longer threshold, a secondary recipient is added so the machine doesn’t sit until Monday.

Suppress repeats by sending one alert chain per stop event until the state returns to running. Then, if it stops again later, that’s a new event. This one rule eliminates the “email storm” that causes people to set filters—and miss the message that matters.

Route by responsibility when possible. A “machine in alarm” may belong to the cell lead first; a repeat spindle overload might need maintenance; a repeat program stop might need the programmer. Even if your first version routes everything to the supervisor, the goal is to evolve toward ownership-based escalation rather than blanket notification.

Review weekly which emails were actionable versus false positives. This is how you tune debounce windows, adjust schedules, and keep the system aligned with shift-to-shift reality. The objective is reduced utilization leakage—lost time between “it stopped” and “someone intervened”—not more admin.

As you scale beyond a pilot, connecting alert events to capacity discussions becomes easier when you have consistent state data. This is where machine utilization tracking software fits: not as a dashboard goal, but as a way to quantify where time is being lost across shifts and cells.

What to do after the alert: close the loop into downtime tracking

An alert is only valuable if it drives a repeatable response and leaves behind clean accountability data. Otherwise, you’ve just moved the “we didn’t know” problem into an inbox.

A simple supervisor response checklist works across shifts: verify the cause (alarm screen, door/estop, tooling condition, material present), restore the run if safe, and then capture a reason code once the machine is stable. Don’t force operators to categorize downtime mid-firefight; you want the spindle turning first, then the classification.

Timestamp the event in three points: stop time, acknowledge time, and running-again time. That creates visibility into response time by shift—often where the ERP vs actual behavior gap shows up most clearly. Over time, this highlights patterns like “stops after midnight take longer to address” or “weekend on-call routing is unclear,” without needing to argue from anecdotes.

Finally, use repeated stop patterns to drive process fixes: tooling standards, program edits, material staging, or clearer handoffs between shifts. The strategic point is to recover hidden capacity before you assume you need another machine. Alerts expose the idle minutes you can actually control.

If you’re thinking about implementation, focus on two realities: (1) you’ll want this to work across modern and legacy equipment, and (2) supervisors need low-friction setup and tuning—thresholds, schedules, recipients—without a long IT project. Cost-wise, evaluate based on how quickly you can pilot on one machine and expand only after the alert is trusted. You can review practical rollout considerations on the pricing page to understand packaging and scaling without getting stuck in a spreadsheet exercise.

Want to sanity-check your stop definition, thresholds, and escalation path on one of your pacer machines? schedule a demo and we’ll walk through an alert design that matches your shift structure, avoids false positives, and closes the loop into downtime accountability.