Key takeaways
Short answer: The andon cord is the operator's authority to stop the line when a defect cannot be fixed at-station. The andon light is the visual signal — green for normal, yellow for help requested, red for line stopped — that broadcasts station status to supervision. Pulling the cord turns the light red. But the light is also used for non-stop signaling (yellow for help). Most plants confuse the two by using only lights and never the cord, which keeps throughput up but destroys the quality discipline the system is supposed to protect. See also Andon System Design.
The andon cord is famously the line-stop authority every Toyota Production System operator has. If a defect cannot be resolved at the station within the takt time, the operator pulls the cord. The line stops. Supervision arrives. The problem is solved before bad parts pass downstream.
The cord is not primarily a tool. It is a cultural commitment. The company is saying: we would rather stop the line than ship a defect. Without that commitment, the cord might exist but nobody uses it because stopping the line gets you punished.
The andon light is the visual status indicator at each station and rolled up to a centralized board.
It is a broadcast information system. Supervision sees the colors from across the floor and responds. It does not require a line stop; yellow is the most common signal.
The cord pull triggers a red light. But yellow lights happen all day for help requests — material running low, minor question, tooling change. The cord is for the rare case where stopping is the right call.
Confusing the two leads to two failure modes:
Most plants today implement andon lights via a software system rather than a literal cord. A button at the station, a screen at the supervisor's desk, an alert to a phone. The principles do not change — the cord function (operator-initiated line stop) needs to exist as a distinct action with its own meaning, separate from routine help requests.
OEE platforms often include andon-style signaling. When tied to downtime capture, the andon light becomes the reason code for an Availability loss, which closes the loop between operator signal and OEE analytics.
1. Implementing lights without the cord function. The visual system exists but no operator has line-stop authority. The plant looks Toyota-style but is not.
2. Making the cord pull a disciplinary event. Operators stop pulling, defects pass, the system rots quietly.
3. Not connecting the light to the downtime database. The supervisor sees the color but the OEE system never learns why the station stopped.
A modern OEE platform lets operators raise yellow or red events with reason codes, routes the alert to the right supervisor, captures response time, and ties every red event to an Availability loss in OEE. The cord function (operator line stop) and the light function (visual status broadcast) remain distinct in the data even though both flow through the same interface.
Fabrico's OEE module supports andon signaling with reason-coded yellow and red events, response-time capture, and direct linkage to Availability loss — keeping the cord/light distinction visible in the data.
See how Fabrico captures this automatically — explore OEE for manufacturing or book a demo.
Some do, especially in automotive. Most use button or screen interfaces with the same authority. The physical cord became iconic but the function is what matters.
No. Yellow signals help requested while running. Red is the stop signal.
Yellow typically routes to the team leader or line supervisor. Red escalates to the supervisor and triggers a stop response that may include maintenance or engineering.
No. Andon is a visual signaling system for help and stops. Kanban is a pull-based replenishment signal. Both come from Toyota; they solve different problems.
Andon is the operator-side mechanism of jidoka (autonomation): the human's ability to stop the line on detected abnormality. They are deeply linked.
Connexion
Blog
