This article is for plant managers, production managers, maintenance and continuous improvement leaders who have installed an andon, or are about to, and want it still to matter six months from now. It addresses a practical question: how to feed the andon with stops reported automatically by the machines, with which thresholds, and how to organize the response so that an alert triggers action instead of indifference. For the fundamentals of andon and line-stop authority, see our andon guide<\/a>.<\/p>\n
Turns yellow, then red if the stop lasts<\/td>\n<\/tr>\n
\n
Cycles slower than nameplate rate<\/td>\n
Speed drift, slowdown<\/td>\n
Yellow alert if the drift persists over a defined window<\/td>\n<\/tr>\n
\n
Repeated micro-stops<\/td>\n
Feeding, setting or sensor problem<\/td>\n
Alert on frequency (stops per hour), not on each micro-stop<\/td>\n<\/tr>\n
\n
Unqualified stop<\/td>\n
No reason has been entered<\/td>\n
Reminder to the team leader to qualify the stop<\/td>\n<\/tr>\n
\n
Operator call<\/td>\n
Quality, safety, material, help<\/td>\n
Stays manual: the person knows<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The principle: the machine says it has stopped, the person says why. Both sources complement each other on the same screen.<\/p>\n<\/figure>\n
Setting duration thresholds: when a stop becomes an alert<\/h2>\n
An andon that turns red at every second of downtime becomes background noise. An andon that waits ten minutes arrives too late. Thresholds are built line by line, with a simple method.<\/p>\n
\n
Start from the nameplate cycle time.<\/strong> It gives the basic unit: a stop is judged in lost cycles, not in absolute seconds.<\/li>\n
Separate micro-stops from stops.<\/strong> Write down the duration below which a stop counts as a micro-stop. Micro-stops do not trigger the andon one by one: you watch their frequency.<\/li>\n
Define the yellow threshold.<\/strong> Beyond the micro-stop threshold, the stop turns yellow and the first level is notified. For example, on a line running a 20-second cycle, a team might choose to turn yellow after 2 minutes of downtime.<\/li>\n
Define the red threshold and escalation.<\/strong> If the stop lasts beyond a second threshold, it turns red and the next level is called. This threshold depends on how critical the machine is: shorter on the bottleneck.<\/li>\n
Review the thresholds after a few weeks.<\/strong> If the andon goes off too often without action, the threshold is too low. If long stops pass without a response, it is too high. Thresholds are tuned on measured data, not on impressions.<\/li>\n<\/ol>\n
Who responds, and how fast<\/h2>\n
The Pulsa article stresses accountability: a visible problem needs an owner. With stops reported automatically, that accountability can be written down in an escalation matrix. Level 1: the team leader or setter, notified at the yellow threshold. Level 2: maintenance or quality, depending on the type of stop, notified at the red threshold. Level 3: the production manager, if the stop hits the bottleneck or exceeds a defined duration.<\/p>\n
Two times deserve tracking. Response time, between the start of the stop and the arrival of the right person. Resolution time, between the start of the stop and the restart. When the start of the stop is timestamped by the machine itself, neither depends on anyone’s memory any more. They become indicators you can review every week, shift by shift.<\/p>\n
Avoiding the andon nobody looks at<\/h2>\n
Many andons end up as decoration. The causes are almost always the same:<\/p>\n
\n
Too many alerts.<\/strong> Thresholds set too low turn every micro-stop into an alarm. The team learns to ignore the screen.<\/li>\n
Alerts without an owner.<\/strong> If nobody is explicitly in charge of responding to yellow, everyone waits for red.<\/li>\n
A screen far from the floor.<\/strong> An andon in an office or at the end of an aisle warns nobody at the right moment.<\/li>\n
Stops never qualified.<\/strong> Without a reason, the history is useless and the same stops come back.<\/li>\n
No review.<\/strong> If the week’s alerts are never discussed in a meeting, the andon stays a reaction tool, never an improvement tool.<\/li>\n<\/ul>\n
The rule that works best: every alert has an owner, every long stop has a reason, and every week the team reviews the ten alerts that cost the most time.<\/p>\n
Linking the andon to OEE and micro-stops<\/h2>\n
The andon and OEE do not answer the same question. The andon says what is happening now and who needs to move. OEE says what the line actually produced compared with what it could have produced, over a shift, a week, a month. The two feed each other: the stops that trigger the andon are the same ones that lower availability, and reported slowdowns weigh on performance.<\/p>\n
Micro-stops are the typical case. One by one, they do not justify an alert. Added up over a shift, they can account for a large share of lost time, invisible on the andon as on manual logs. Measured OEE, with a Pareto of stops by duration and frequency, is what brings them to light and supports the decision to launch an improvement project.<\/p>\n
This is where TEEPTRAK fits. A module wired into the electrical cabinet and an edge-mounted sensor at the line automatically detect stops, micro-stops and actual speed, with no connection to the PLC. Installation takes about one hour per machine and OEE is available within 48 hours. Timestamped stops can feed alerts and the weekly review, while the team keeps control over qualifying the causes. TEEPTRAK is deployed in more than 700 plants in more than 30 countries.<\/p>\n
![\"Four-step](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/11\/teeptrak-andon-automatique-en.png\")
<\/figure>\n