{"id":157373,"date":"2026-11-02T16:08:38","date_gmt":"2026-11-02T16:08:38","guid":{"rendered":"https:\/\/teeptrak.com\/downtime-spike-signal-or-noise-control-chart\/"},"modified":"2026-11-02T16:08:38","modified_gmt":"2026-11-02T16:08:38","slug":"downtime-spike-signal-or-noise-control-chart","status":"publish","type":"post","link":"https:\/\/teeptrak.com\/en\/downtime-spike-signal-or-noise-control-chart\/","title":{"rendered":"Downtime spike: real signal or noise? Control chart rules for daily stops and scrap"},"content":{"rendered":"
This article is for plant managers, production managers, maintenance leaders and continuous improvement engineers who look at a weekly downtime report and have to decide, often in a Monday meeting, whether a bad week deserves an investigation or just a note in the minutes. It shows how to apply control chart rules to two numbers most plants already collect every day, the count of machine stops and the count of scrap parts, so that the team reacts to real signals and stops chasing noise.<\/p>\n
\n
In short<\/div>\n
\n
A single bad day is not always a real change in the process.<\/li>\n
Daily stop and scrap counts fit simple attribute control charts.<\/li>\n
A short set of agreed rules separates signals from noise.<\/li>\n
Reliable, automatic stop data makes the chart trustworthy.<\/li>\n<\/ul>\n<\/div>\n
The Monday meeting problem: every bad week looks like a crisis<\/h2>\n
Picture a familiar situation. For example, a line that usually logs somewhere between 15 and 25 stops per day shows 31 stops on Wednesday. Someone asks what happened, a maintenance technician is pulled off planned work, an action is opened, and by Friday the count is back to its usual level. Was Wednesday a real change in the process, or one of the high days that a stable process produces from time to time? Without an agreed rule, the answer depends on who speaks loudest in the meeting.<\/p>\n
The opposite mistake is just as costly. A slow drift, for example two or three extra stops per day over three weeks, never looks dramatic on any single day, so nobody reacts until the monthly report shows availability going down. By then, the cause (a worn component, a new material batch, a changed setting) has had weeks to do damage.<\/p>\n
Both errors come from the same habit: comparing today’s number with yesterday’s number, or with a target, instead of comparing it with the process’s own natural variation. That is precisely the job of a control chart.<\/p>\n
Jay Arthur’s point: SPC is not as hard as people think<\/h2>\n
![\"Four-step](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/11\/teeptrak-spc-downtime-en.png\")
<\/figure>\n