Somewhere right now there is a supervisor whose phone has buzzed forty times this shift, and who has stopped looking at it. Nobody decided this. It happened the way it always happens, one plausible alert at a time, each individually defensible, collectively unbearable, until the human at the end of the pipe did the only rational thing available and tuned out. The vendor will call this user error. The supervisor will call it self-preservation. Both are wrong about where the failure lives, because alert fatigue is not a personality problem or a product defect, it is a configuration debt that accumulates when a detection system is deployed faster than it is tuned, and it is the single most common way monitoring projects die. This article is about paying that debt down deliberately, and it belongs to our full guide on AI for workplace safety in manufacturing.
Run the alert volume math before go-live
Start with the numbers a deployment actually produces, because they explain everything that follows. A modest site runs forty cameras. Each camera watches for a handful of detection types, and each detection type fires some number of times per day, mostly correctly in the narrow sense, the object really was there, and mostly uselessly in the operational sense, because the person in the walkway was allowed to be there and the vehicle at the dock was doing its job. Multiply small per-detection-type rates by detection types, cameras, and twenty-four hours, and a system that is 95 percent quiet still produces a hundred events a day. Now decide what fraction of a hundred daily events a working supervisor can genuinely evaluate. The honest answer at most sites is somewhere under ten, and the gap between what the system emits and what a human can absorb is the fatigue budget. Every deployment has one. The only question is whether it gets spent by design or by attrition.
The clinical literature on alarm fatigue in hospitals reached the same conclusion years ago, and the mechanism transfers exactly: when most alarms do not require action, response degrades to all alarms, including the ones that do. The floor does not distinguish between a badly tuned system and an untrustworthy one, because from where the floor stands there is no difference.
Confidence and severity do different jobs
The tuning model that keeps the budget spendable has two controls per detection type per camera, and understanding what each is for prevents the most common mistakes.
Confidence is the model's certainty threshold, how sure the detector must be before a detection counts at all. It governs the false-positive rate at the perception level: raise it and marginal detections, the half-occluded object, the reflection, the distant maybe, stop counting; raise it too far and real events start dying silently, which is the failure you cannot see happening. Confidence is a per-camera matter because it is really a per-view matter, the same detection type running against clean lighting on one camera and against glare and distance on another, and a threshold copied between them transfers the number without transferring the meaning.
Severity is a different kind of judgment entirely: how much this detection type matters here. It does not change what is detected, it changes what happens next, whether an event pages someone now, lands in a queue for review, or logs quietly for the trend line. A person in the robot cell and a person in a marked walkway are both detections; one is severity that pages, the other is severity that counts. Setting severity is not a data-science task, it is a safety-judgment task, and the people equipped to make it are the ones who own the zones, which is why tuning done entirely by the integrator produces a system the site never quite believes.
The third control hides in plain sight and gets missed because it looks like infrastructure: what happens on the delivery side. Per-camera subscription means the dock alerts go to the dock's owner rather than to everyone, and escalation paths mean an unacknowledged high-severity event climbs to the next person instead of expiring in an inbox. A perfectly tuned detection layer wired to an undifferentiated distribution list reproduces the fatigue problem one hop downstream.
The tuning sequence that works
The sequence that fails is the one that feels productive: enable everything, everywhere, at defaults, and plan to tighten later. Later arrives after the credibility is gone. The sequence that works inverts it, and the first article in this series on hazard zones sketched it; here is the fuller version a site can run as a project plan.
Weeks one and two of the sequence run completely silent. Every intended detection type and zone runs, nothing pages anyone, and the system does nothing but accumulate a baseline: what fires, where, how often, at what confidence. This baseline is the most valuable dataset the deployment will ever produce, because it is the only period where the numbers describe the site rather than the site's reaction to the numbers.
Week three is the reading of everything the silent period collected. For each camera and detection type, look at the distribution of confidence scores for events supervisors confirm as real against those they wave off, and set the threshold where the populations separate. Some cameras will show no separation, which is the data's way of saying that view cannot support that detection type, and retiring it there is a finding, not a defeat. This is also the week severity gets assigned by the zone owners, type by type, camera by camera, in an afternoon workshop that doubles as the training session.
Weeks four through six are the graduated ramp: paging on for the highest-severity, best-separated detection types first, one tier at a time, each tier proving itself quiet before the next joins. The discipline that matters during the ramp is the weekly false-positive review, twenty minutes with the log, asking one question of every noisy source: redraw, rethreshold, or retire. Deployments that keep that twenty-minute habit stay tuned for years. Deployments that skip it are back to the buzzing phone by summer.
There is one asymmetry worth engraving on the process: a false positive costs a glance, a suppressed true positive costs whatever the event was. Tuning pressure should therefore always push noise down through scoping and severity, zones drawn tighter, delivery routed better, rather than through cranking confidence to the ceiling, because confidence is the one dial whose overtightening fails invisibly.
Give every alert a lifecycle
Even a well-tuned system needs somewhere for events to go, and the difference between a queue and an inbox is accountability. An inbox accumulates; a queue has states. The working pattern gives every alert a lifecycle, raised, acknowledged, resolved, with a disposition recorded at the end: confirmed and acted on, confirmed and referred, false positive with reason. That last category is not bureaucracy, it is the fuel for the weekly tuning review, because a false positive with a reason attached, wrong zone edge, glare after 4 p.m., contractor work in progress, is a fix waiting to be applied, while an ignored alert teaches the system nothing and the operator everything wrong.
The dispositions also produce the supervision layer's honest picture. A dashboard that shows open alerts by age and severity, rather than a rolling feed, lets a shift lead see in one glance whether the site is keeping up, and the aging high-severity alert becomes visible as the process failure it is rather than vanishing under newer noise. Sites that run triage this way discover something counterintuitive: total alert volume matters less than they feared, because a hundred events a day that resolve to a dozen acknowledged actions and a documented false-positive list is a functioning system, while thirty untracked events is a dying one. Volume is the symptom people notice; the absence of workflow is the disease.
Retune every season
A threshold set in February meets a different plant in July. Summer light angles push glare across lenses that were clean all winter, seasonal product changeovers alter where material stages and how traffic flows, holiday-cover staffing changes who responds and how fast, and outdoor cameras meet rain, snow, and insects with opinions of their own. None of this means constant fiddling; it means the tuning calendar should acknowledge that configuration decays. A quarterly pass over the same evidence the commissioning used, confidence separation by camera, false-positive reasons from the triage log, acknowledgment rates by zone, catches the drift while it is still cheap, and the sites that schedule it treat retuning as maintenance, in the same category as cleaning the lenses, which is exactly the right category.
Measure alert fatigue
Because fatigue accumulates quietly, mature deployments measure it the way they measure any other operational risk. Three numbers do it. Acknowledgment rate: what fraction of paged alerts get a human response, tracked by zone and shift, with decline as the early warning. Time-to-acknowledge for the highest severity tier, because drift there is the direct measure of eroding trust in exactly the alerts that must never be doubted. And alerts per operator per shift against the honest capacity number from the arithmetic above, because when the emitted volume exceeds the absorbable volume, the excess is not being triaged, it is being ignored, whatever the org chart says.
These numbers belong in the same monthly review as the detection program's other health checks, and they close the loop with the safety Key Performance Indicator (KPI) framework this series covers: exposure indicators tell you what the site is doing, fatigue indicators tell you whether anyone is still listening.
Watch for dead cameras
Fatigue management obsesses over the alerts that arrive, and the deadlier failure is the alert that cannot. A camera that goes dark, loses its stream, or drifts out of position produces no events, and in a fatigued environment nobody notices the silence, because silence is what everyone was hoping for. The zone it covered is now unmonitored while every dashboard shows green, which is a worse posture than having no system at all, since the site is now confident about coverage it does not have. Camera health monitoring belongs in the same review as threshold tuning for exactly this reason: stream status and downtime tracked per camera, a health alert treated with the same severity discipline as a detection, and a periodic coverage audit that walks the zone list against the camera list asking one question, if this camera died on Friday night, when would we know. The deployments that survive their third year all have a boring answer to that question.
How VIDIZMO handles it
The tuning model described here is how VIDIZMO AI Live Insight is actually configured. Confidence and severity are set per detection type per camera rather than globally, zone rules carry their own severity and target type so one camera can page for the robot cell while logging for the walkway, and alert subscriptions are per camera with the snapshot attached, so the person paged can evaluate from the phone without a walk. Detection runs on the customer's own hardware on site, reading the cameras the plant already owns, and inference cadence is itself configurable per deployment, which is part of the same budget: the cameras whose events warrant per-frame scrutiny get it, and the wide-coverage cameras run at an interval that keeps the hardware honest. Every event, paged or not, lands on the timeline with its clip in the Nexus portal the deployment works alongside, which is what makes the weekly false-positive review a twenty-minute job with evidence rather than an argument from memory.
One configuration habit ties the whole chapter together: write the tuning decisions down. The threshold chosen for camera 12, the detection type retired from camera 30, the severity map agreed in the workshop, each with its date and its reason, kept beside the zone register. Six months later, when someone asks why the press bay pages and the dock does not, the answer is a document rather than an archaeology, and the next retuning pass starts from recorded intent instead of reverse-engineering its own system.
If a site takes one thing from this article, it should be the shape of the first six weeks: silent, then read, then ramp. The systems that die of fatigue almost all skipped straight to noise, and the floor never forgave them for it.