Andon — Andon is a visual system used to signal problems in real time so they can be addressed immediately.
In plain English
Andon is a visual signal system that shows a problem right when it happens. It exists so issues get noticed fast and fixed before they turn into bigger defects, delays, or safety risks.
Andon usually uses lights, screens, sounds, or buttons at the work area. When someone sees a problem, they trigger the Andon. The signal tells other people what line or station has trouble and what kind of help is needed. A leader or support person comes to the spot, checks the issue, and helps remove the cause. The goal is to restore normal work and prevent the same problem from coming back.
What they actually mean
On paper, Andon is simple: see problem, signal, respond, fix.
In reality, many organizations quietly punish the person who pulls it. So the system becomes decorative. The light is there. The button is there. Nobody touches it unless a VIP is walking through.
Common misuse looks like this:
- Teams are told “don’t stop the line” unless it’s catastrophic.
- Supervisors treat pulls as a performance issue instead of a process signal.
- Response becomes a blame huddle: “Who did this?” not “What changed?”
- Support functions show up late, then argue about ownership (maintenance vs quality vs production).
- Andon events get logged, then die in a spreadsheet with no follow-up.
Uncomfortable truth: If you don’t have fast response and a way to remove repeat causes, Andon is just a way to make problems louder.
Often confused with a weak escalation process or used as a substitute for real standard work. When done right, it’s boring: clear pull criteria, help arrives in minutes, the team contains the issue, and repeat triggers feed root cause work that actually changes the process.
Example
On a packaging line, the case sealer starts leaving one corner open about once every 20 boxes. The operator pulls Andon after the third open corner in a 10-minute window, because the pull rule is “any repeat defect in the same station.” The team lead arrives and checks the tape head. The tape roll tension is drifting because the brake pad is worn and the roll is free-spinning during acceleration.
They swap the brake pad from a prepared kit, re-thread the tape, and run five test cases. Quality verifies the seal. The line restarts within eight minutes. The Andon record triggers a maintenance task to replace brake pads on a schedule and a parts min/max update so the kit stays stocked.
Where you’ll hear it
You’ll hear “pull Andon” in places where work is repeatable and problems show up fast: assembly lines, packaging, test cells, warehouses, and high-volume service desks with live queues.
“If you can’t meet the standard, pull Andon and we’ll come to the point of use.”
Does it actually matter?
✅ Yes — when you have repeatable work and you care about quality, safety, or flow.
Andon matters because it shortens the time between “problem happened” and “help arrived.” That reduces scrap, rework, and hidden defects. It also makes abnormalities visible so leaders can prioritize fixes based on real signals, not gut feel. If response is slow or the team can’t change anything, Andon turns into noise and people stop pulling. The value comes from fast support, clear pull criteria, and closing the loop so repeat issues get eliminated, not normalized.
Common misconceptions
- Andon is just a light or a cord → The hardware is the easy part; the response process is the system.
- Pulling Andon means you failed → It means the process is outside the standard and needs help.
- Andon is only for stopping the line → It can be a “call for help” without a full stop, depending on risk.
- More Andon pulls means the team is worse → It often means problems are finally being surfaced instead of hidden.
- Logging Andon events is the same as improving → Logs without cause removal just document recurring pain.
Red flags
- 🚩 People ask permission before pulling Andon.
That adds delay and trains the team to work around defects instead of surfacing them. - 🚩 Response time is undefined or routinely missed.
If help arrives late, operators build rework piles and the signal loses credibility. - 🚩 Leaders use Andon pulls in performance write-ups.
It drives under-reporting, so problems move from visible to hidden. - 🚩 No clear pull criteria by station.
Without rules, you get either constant pulls (alarm fatigue) or none at all (silent failure). - 🚩 Same issue appears on Andon week after week.
That’s proof the system stops at containment and never reaches root cause removal.
Worth learning?
5/5
Worth learning because it forces real-time problem visibility and disciplined response. It works best when paired with clear standards, quick support, and follow-through that removes repeat causes.
Deep dive
Andon is a core method from lean manufacturing, most associated with the Toyota Production System. The original idea is not “make a noise when something goes wrong.” The idea is: make abnormalities visible immediately, respond immediately, and use those signals to improve the system. The signal is the trigger. The real method is the response and the learning loop.
What Andon is (operationally)
Andon is a real-time signaling mechanism tied to a defined standard. When the work cannot be performed to standard (time, quality, safety, material, tool condition), someone triggers a signal. That signal prompts a fast, structured response at the point of use. The response is meant to:
- Contain the immediate risk (don’t ship bad product, don’t hurt someone, don’t bury defects).
- Restore flow (get the process back inside standard quickly).
- Capture what happened (so it can be prevented, not repeated).
In many environments, Andon is implemented as a stack light (green/yellow/red), a cord, a button, a touchscreen, or a digital alert. The physical form does not define the method. The method is: signal + response + closure.
Why it exists
Most operations fail slowly. A small issue starts, people work around it, and the workaround becomes “how we do it.” Then you discover the damage later: a quality escape, a missed shipment, an overtime weekend, or a safety incident. Andon exists to shorten the feedback loop. It makes “we are off standard” visible now, not at end-of-shift, end-of-week, or after a customer complaint.
It also fixes a leadership problem: managers cannot improve what they cannot see. Without Andon, visibility comes from anecdotes, delayed reports, and whoever complains loudest. With Andon, the work tells you where it hurts.
How it works when it’s real
A functioning Andon system has a few boring, specific pieces:
- Clear standards. People know what “normal” looks like: cycle time, quality criteria, torque spec, label placement, queue limit, etc. If the standard is vague, the signal is arbitrary.
- Defined pull criteria. Each station or work area has simple rules for when to call: first-time defect, repeat defect threshold, missing part, tool out of calibration, safety concern, can’t meet takt, no material, and so on.
- Immediate response roles. Someone is accountable to respond within a set time. Typically: team lead first, then maintenance/quality/engineering as needed. The roles are explicit so the operator isn’t negotiating while the line bleeds.
- Containment and restart path. The responder helps contain the issue and decides: keep running with support, pause briefly, or stop. The decision is based on risk, not pride.
- Simple capture. The event is recorded with minimal friction: station, time, category, quick description, and disposition. Not a novel. Not a punishment form.
- Closure mechanism. Repeat issues trigger structured problem solving. That can be a short root cause activity, a maintenance PM update, a tooling change, a training update, or a standard work revision.
Notice what’s not in the list: “make a dashboard.” Dashboards come later, if at all.
Common failure pattern (and why it happens)
Andon fails in predictable ways because it forces the organization to confront its own incentives.
1) The culture says ‘don’t stop the line.’
Many sites optimize for looking busy and hitting hourly numbers. In that world, Andon is threatening because it creates visible downtime. So leaders quietly discourage pulls, or they set unofficial rules like “only pull if you’re bleeding.” The result is hidden rework and quality debt. The line looks green while the back room fills with problems.
2) Response is slow or inconsistent.
If the team lead is covering three areas, or maintenance is always in a meeting, response becomes random. Operators learn quickly: pulling Andon won’t help, it will just attract attention. So they improvise, bypass, and keep running. The system trains people to be silent.
3) The pull becomes a blame event.
If every pull triggers interrogation, people avoid pulling. Leaders often think they are driving accountability. What they are actually doing is driving under-reporting. The only Andon pulls you’ll see are the ones that cannot be hidden.
4) Everything becomes an Andon.
Without criteria, people pull for anything and everything. That creates alarm fatigue. When the signal is always on, it becomes background noise. Then the day a real safety or quality issue happens, the system does not get the attention it deserves.
5) It stops at containment.
The team gets good at quick fixes: adjust, tighten, re-thread, reboot. That’s useful. But if the same failure repeats daily, you are not improving; you are coping efficiently. Andon is supposed to feed root cause work and standard updates. If it doesn’t, you just built a faster way to tread water.
What good Andon metrics look like
Organizations love counting pulls. Counting pulls is not meaningless, but it’s not the point. Better indicators include:
- Response time by category and area (median and worst-case).
- Repeat rate (same station/same issue recurring).
- First-pass yield and scrap/rework trends after fixes.
- Time to close repeat-cause actions (not just log them).
Healthy systems often see an initial increase in pulls because people start surfacing reality. Then pulls decrease as causes are removed. If leadership panics during the “more visibility” phase, the system dies.
Digital Andon vs physical Andon
Digital Andon can work well, especially in warehouses, service operations, and distributed teams. But it has the same constraints:
- If the alert doesn’t reach someone who can help, it’s just a notification.
- If it creates tickets without urgency, it becomes backlog.
- If it isn’t tied to a standard, it becomes “FYI spam.”
Physical Andon has one advantage: it’s hard to ignore. That’s why some companies prefer it on the floor. But physical signals still fail if response and closure aren’t built.
Integration with other systems
Andon works best when it fits into how the operation already runs:
- Standard work defines what “normal” is and what to do before pulling.
- Escalation defines what happens when first response can’t restore within a time box.
- Root cause work removes repeat triggers and updates standards.
If those systems are weak, Andon becomes a spotlight on dysfunction. That can still be useful, but it will feel painful until leadership chooses to fix the system instead of dimming the light.
What it looks like when done right
It looks calm. The operator pulls without fear. The team lead arrives fast. They confirm the abnormality against the standard. They contain and restart safely. The event is captured in a simple way. Repeat issues get worked, and the fix shows up as a change in standard work, maintenance schedules, training, or design. Over time, the line stops less, quality escapes drop, and people stop needing heroics to hit the plan.
Andon, done right, is not a drama generator. It’s a discipline that makes problems visible early, when they’re still cheap to fix.
Report an error
Found something wrong or misleading? Let us know — we want this site to stay fact-based (even when we joke).