Andon metrics are the numbers that tell you whether your andon system actually works: how fast someone responds to a call, how long the line stays stopped, how many calls happen per shift, and how much time each station spends in the red. An andon light that no one answers quickly is decoration; these metrics are how you tell the difference.
Most plants install an andon system cords, buttons, stack lights, or a digital board, and then never measure it. The signal turns red, someone eventually shows up, the line runs again, and no one asks how long "eventually" was. That gap is where andon quietly stops working. This guide covers the handful of metrics worth tracking, how they connect to downtime and OEE, and how to start measuring without a big system.
What are andon metrics?
Andon metrics are performance measures of the call-and-response loop an andon system creates. When an operator raises a signal, a problem, a shortage, a quality issue, the andon starts a clock. Andon metrics time and count what happens next: who responded, how fast, how long the fix took, and how often the whole thing repeats.
They exist because andon is a promise, not just a light. The promise is that a raised hand gets a fast answer. The metrics test whether the promise is kept. Without them, andon degrades into a light people ignore, and the system that was supposed to surface problems fast becomes one more thing that blinks on the wall. Because every andon call for a stoppage is also a downtime event, these metrics feed straight into your downtime tracking and the availability factor of OEE.
What are the core andon metrics to track?
A short list does the job. Track these, not twenty:
- Response time (time to acknowledge). From call raised to a responder physically at the station or acknowledging the call. This is the headline andon metric, it measures whether the system gets attention. Target it in minutes, not "when someone's free."
- Resolution time (time to resolve, or MTTR). From call raised to line running again. This is the mean time to repair for andon events, and it is what actually costs production minutes.
- Calls per shift (or per hour). Volume. Rising call counts can mean a deteriorating process, or a healthy culture where people finally feel safe to pull the cord. Read it alongside the other numbers.
- Time in red (downtime by station). Total minutes each station spends stopped or waiting per period. This is the Pareto view: which station bleeds the most.
- Escalation rate. Share of calls that had to escalate to the next tier because the first responder couldn't resolve them in the target window. High escalation points at a training or staffing gap.
- Repeat-call rate. Share of calls for a problem seen before. High repeats mean the fixes are patches, not root-cause solutions, a signal to route those into root-cause analysis.
Why measure the andon system instead of just installing it?
Because an unmeasured andon degrades on its own. The failure mode is quiet: a call goes unanswered for eleven minutes one day, fourteen the next, and because nobody times it, the slide is invisible until operators stop calling at all. Once operators learn that pulling the cord changes nothing, they stop pulling it, and the plant loses its early-warning system exactly when it needs it. Response time is the vital sign that catches this before it happens.
Measuring also reframes what a rising call count means. A team that suddenly logs more andon calls has often gotten healthier, not worse, people trust the system enough to use it. You can only tell the difference between "more problems" and "more honesty" if you watch response time and repeat-call rate alongside volume. Andon is a lean signal in the jidoka tradition: stop, surface, and fix at the source. The metrics are what keep it honest.
Escalation rate deserves special attention here, because it is the metric that exposes a broken response structure. A well-designed andon has tiers, the operator calls, the team lead responds, and if the lead cannot resolve it in the target window, the call escalates to maintenance or the shift manager. Some escalation is healthy; a system where a quarter of calls jump straight past the first tier is telling you the first tier is either understaffed or undertrained. Watching escalation rate over time is how you know whether your response structure matches the problems the floor actually throws at it, rather than the ones you designed for on paper.
How do andon metrics connect to MTTR and availability?
Resolution time is MTTR for andon events, and MTTR is one of the two levers on availability loss. Every minute a line sits in the red waiting for a response, or waiting for a fix, is availability lost, it comes straight out of run time in the availability rate. So andon response time is not a soft "culture" metric; it converts directly into OEE points.
The connection cuts both ways. Slow response inflates the breakdown bucket in your availability loss analysis and a high repeat-call rate means the same downtime keeps coming back because fixes are shallow. Cutting response time attacks MTTR; cutting repeat calls attacks MTBF. Andon metrics, downtime, and OEE are the same story told at different zoom levels, which is why they belong on the same plant scorecard.
The scale is easy to underrate. The U.S. Federal Reserve's G.17 release put manufacturing capacity utilization at 75.7% in May 2026 roughly 2.5 points under its 1972–2025 average, a reminder that real plants leave a lot of capacity on the table, and slow response to line stops is one avoidable slice of that gap. Against the commonly cited world-class availability reference of 90% (part of the 85% OEE benchmark from Nakajima's TPM work), a few extra minutes on every andon call is the difference between a line that hits target and one that chronically misses. Neither figure is an andon benchmark; both frame why shaving response time is worth staffing.
How do you start tracking andon metrics?
You do not need a big system to begin. Start simple and tighten:
- Define the call. Decide what counts as an andon event and what the tiers are, station, team lead, maintenance, plant manager. Ambiguous triggers make every downstream number mushy.
- Timestamp two moments at minimum. Call raised and line running again. Those two give you resolution time immediately. Add an acknowledge timestamp to split out response time.
- Set a response-time target and post it. A visible target, "respond within 3 minutes", turns the metric into a standard people can meet or miss. Without a number, "fast" is an opinion.
- Log a reason code per call. Machine fault, material short, quality, safety. Reason codes are what let you Pareto the calls later and route repeats to root-cause.
- Review the top station weekly. Rank time-in-red by station, take the worst one, and ask why. Rotate the focus as the constraint moves.
- Close the loop on repeats. Any problem that generates a third call in a month goes to a structured root-cause review, not another quick patch.
What does a good andon scorecard look like?
Small and honest. The numbers below are hypothetical shown to illustrate the shape of a weekly andon review rather than to state any benchmark.
| Metric | This week | Target |
|---|---|---|
| Avg response time | 4.2 min | ≤ 3 min |
| Avg resolution time (MTTR) | 17 min | ≤ 15 min |
| Calls per shift | 11 | trend |
| Escalation rate | 22% | ≤ 15% |
| Repeat-call rate | 31% | ≤ 20% |
Read as a set, this scorecard tells a story: response is a bit slow, escalation is high, and nearly a third of calls are repeats. The plant does not have a volume problem, it has a resolution-quality problem. That is a different fix (better first-tier training and real root-cause work) than "operators call too much," and only the metrics surface it.
How reliable are hand-logged andon numbers?
Less than you would like, in the same way hand-logged downtime is. When response and resolution times depend on someone remembering to note two timestamps during a stoppage, the fast calls get logged and the ugly ones, the ones you most need to see, get reconstructed later or skipped. The result is an andon scorecard that flatters the very responses it should expose. Capturing the timestamps automatically, from the andon trigger and the machine's run state, removes the temptation and the guesswork.
Harmony ties andon calls to machine signals, so a stop, its reason, and the response clock are recorded as they happen rather than pieced together at shift end (see the platform or the CLS field results). That is what makes response time a number you can hold a shift to. From here, the same events roll up into downtime and the OEE calculation andon metrics are the fastest, most human-visible edge of the same measurement system.