Here's the verdict up front: spend 10 minutes on a WCS daily check before the first wave goes out. Five metrics, in this order: equipment online rate, task queue depth, alarm count, communication status, and the upstream WMS heartbeat. I've seen this mistake three times, across 30+ go-live projects—teams that skip the 10 minutes to "save time" end up losing at least 30 minutes of downtime within the quarter. Every time.
The WCS Daily Check: 5 Metrics and Their Thresholds
The metrics themselves are easy. The thresholds are what matter. Without thresholds, a monitoring dashboard is just expensive wallpaper. Below is the generic version I hand to every site; tune it against your own WCS vendor's SLA on first use.
| Metric | Green (normal) | Yellow (act) | Red (stop the line) |
|---|---|---|---|
| Equipment online rate | ≥ 98% | 95–98%: confirm each offline unit before waving | < 95%: stop and troubleshoot |
| Task queue depth | < 200 pending tasks | 200–500: drain before releasing new waves | > 500: stop and drain |
| Alarms (last 2 hours) | ≤ 3, all acknowledged | any unacknowledged alarm | ≥ 10, or the same alarm repeating |
| Communication (PLC / scanners / AMRs) | all connected | individual devices reconnecting | main-line PLC down, or any critical device offline > 10 min |
| WMS interface heartbeat | last heartbeat < 5 sec | 5–30 sec | > 30 sec, or heartbeat timeout |
The rule of thumb: green means go, yellow means go slow, red means stop. More on why yellow doesn't stop the line later.

How to Run the WCS Daily Check in 10 Minutes
Lock the clock. Lock the actions. Don't stand there staring at the screen.
Minutes 0–2: equipment online rate. Open the WCS device overview and count what's offline. Is it a main-line device or auxiliary? A spare pack station being down is a yellow—wave anyway. A main-line PLC down is red, full stop. Make that call within 2 minutes, not after the shift supervisor finishes the morning huddle.
Minutes 2–4: task queue depth. Look at pending tasks. Did the night shift leave a tail? During peak season, they always do. Queue at 200–500? Manually release a batch of old tasks first to drain pressure. Never stack the first fresh wave on top of yesterday's backlog.
Minutes 4–6: alarms. Review the last 2 hours. Two things matter: unacknowledged alarms, and the same alarm repeating from the same device. A repeating alarm is the system writing you a letter. Read it.
Minutes 6–8: communication status. Page through PLC, scanner, and AMR connection status. This one gets skipped the most, because when communication is healthy, the screen shows nothing at all.
Minutes 8–10: WMS heartbeat + trial run. Confirm the heartbeat, then manually release a tiny wave of 5 orders as a trial. A healthy heartbeat is not the same as healthy semantics. The trial run tells the truth.
Who owns it? Don't expect operators to squeeze this in between tasks. Add a "queue depth" line to the night-shift handover log, and write the check owner's name on the control-room whiteboard. On my projects, the control-room operator on duty runs the 10 minutes, and the shift lead reviews anything yellow or worse. A checklist with no owner is a piece of paper. And archive the result—a daily screenshot of the threshold readings, exported from the WCS. When something goes wrong, you want evidence, not memories.
What a Failed Startup Looks Like: The Queue Nobody Checked
Let me give you a specific one. Mid-June 2024, a beauty e-commerce warehouse in Xiaoshan, Hangzhou, one week before a big promo. The night shift clocked out at 10 PM with 1,180 pending tasks sitting in the WCS—leftover promo orders from the day, plus a backlog from a palletizer failure that had been patched with manual labor all afternoon. The night lead glanced at it and went home.
Next morning, 8 AM, the operator released the first wave of 600 orders on a normal schedule. By 8:40 the queue had blown past 2,400. Every sortation chute on the main conveyor was jammed; stuck totes backed up into the cases behind them; the safety light curtain tripped and the whole line e-stopped. It took 42 minutes to clear. All 32,000 orders that day shipped late, and customer service got flooded.
The debrief question was simple: did anyone look at the queue that morning? No. Had someone looked, that 1,180 would have blown past the yellow line of 500 on sight. That 500 threshold isn't guesswork—a typical conveyor line's buffer can absorb roughly 300 orders; past 500, you genuinely can't push through, and you must drain before releasing new waves.
Here's another one, and this pit I've seen three times. November 2023, a 3PL warehouse in Kunshan. Shift started with a spotless alarm panel: zero alarms. The operator thought it was going to be a lucky day. At 9 AM the palletizer jammed; the technician found that the alarm-forwarding service had died at 2 AM—17 alarms from the PLC side, not one of them reaching the WCS screen. The counter-intuitive judgment: zero alarms is scarier than ten alarms. Ten alarms at least prove the alarm pipeline is alive. Our WCS daily check now has a standing rule: if you see zero alarms for three consecutive mornings, check that the alarm service is still running before you celebrate.
And a third, from February 2025, a cross-border warehouse in Shenzhen. The WMS was redeployed at 3 AM; heartbeat looked normal. First wave at 7 AM, and for 40 minutes not a single order came down. The redeploy had changed the wave ID format, which the WCS couldn't recognize—heartbeat fine, semantics broken. That's why minutes 8–10's five-order trial run is non-negotiable. A heartbeat is a heartbeat; business is business.
The Trade-Off: Yellow Is for Slow, Not for Stop
This is the argument every site has. Yellow action line triggered—do you stop the line to troubleshoot, or wave at reduced speed and fix on the fly?
My answer: only red stops the line. Yellow goes slow. Do the math. Stopping the line, even for 15 minutes, means idle labor across the floor, delayed waves, and a cascading late start for the next shift. That cost is certain. Waving at reduced speed—say 70% throughput—keeps product moving and money flowing. The risk is bounded: yellow means someone is watching, ready to escalate to red.
The decision frame is simple; tape it next to the threshold table:
| Situation | Action | Decided by |
|---|---|---|
| Single yellow (e.g., queue at 300) | wave at 70% speed, named person on the screen | control-room operator can decide |
| Two yellows stacked | wave at 50% speed, shift lead on the floor | shift lead decides |
| Any red | stop the line, troubleshoot, no waving | shift lead or above |
Note the middle row: yellows stack. A queue of 300 alone is yellow; one scanner dropping off communication is also yellow. But two yellows together don't add—they multiply. At that point, running at 50% or treating it as red are both defensible calls. The threshold table is fixed; the stacking judgment is live, and it belongs to whoever is watching the screen.
One iron rule, though: a yellow-line startup must have a named person watching the screen. Yellow with nobody watching is just green by wishful thinking.
Print this checklist and tape it to the control-room wall. It should be page one of your go-live night checklist. Ten minutes, five metrics, every morning. It will cut your line-stop incidents at least in half per quarter. I won't promise more than that, because the other half is human error, and no checklist fixes that.
By Lin Xiao, WMS Implementation Consultant






