Warehouse metrics
Released and cleared are twodifferent moments for a wave.
Wave completion rate is the share of released waves that actually close — every pick, pack and staging task confirmed complete — inside the window the wave was released for, rather than stalling, rolling into the next release, or needing a supervisor to force it shut. WareBee reads wave-open and wave-close events off the same schedule that times the release itself, so a wave that never quite finishes is visible as its own outcome, not folded into whatever the next wave manages to clear.
See where the plan actually broke
What it is
Closed, rolled over, or forced shut: three outcomes for a wave.
Wave completion rate is the share of released waves that reach genuine completion — every pick, pack and staging task inside that wave confirmed done — before the window that wave was released for runs out. WareBee captures the release itself as an event and watches for the moment the last task inside it closes, so a wave that clears cleanly, a wave that limps to a close with tasks pushed into the next release, and a wave a supervisor has to force shut to keep the schedule moving are recorded as three different outcomes, not one pass-or-fail flag applied at the end of the shift.
The number moves with what a wave was actually asked to carry, not with how closely the shift tracked its plan minute by minute — that's a related but separate question. Whether the release itself was timed to the pick rate and equipment cycle already running in that zone or forced out on a fixed clock, whether the batch inside the wave was one the floor could realistically clear in the window given, whether replenishment kept the pick face stocked as the wave worked through it, and whether the wave ahead of it finished on schedule or was still clearing when this one released, all decide whether a wave closes clean or has to be dragged over the line.
Whether a wave should be expected to close inside its window depends on what was ever inside it — a site releasing tightly batched waves with high SKU overlap is asking something different of its floor than one releasing loosely batched waves built from single, unrelated orders, and no single completion rate could stand for both. Order profile, SKU count and footprint are what decide that difference, so a reading only becomes meaningful once it's checked against sites carrying a genuinely similar release pattern — a rate that looks low against nothing in particular can still be exactly where waves like yours normally land.
What moves this number
Every stalled wave has a stage it stalled at.
Each one is measured on your digital twin from data you already generate, so a wave that rolled over has a specific cause before the next release inherits the same problem.
How the release itself was timed
A wave released on a fixed clock rather than against the pick rate and equipment cycle already running in that zone starts behind before the first pick happens.
WareBee times wave release against actual pick rates and equipment cycle times for that zone rather than a fixed interval, so labour and equipment arrive to open space instead of a queue still clearing the previous wave's pack line.
Whether the batch inside it was walkable
A wave built from a batch too large, or with too little SKU overlap for the window given, asks the floor to cover more ground than the release allowed for.
Order profile — lines per order, SKU overlap, cube and weight — decides whether a given batch size clears cleanly in the time a wave has, and WareBee simulates candidate batch policies against your real orders before one reaches a live wave.
Whether the pick face stayed stocked
A picker reaching an empty location partway through a wave loses time the release window never accounted for.
Replenishment sequenced against the pick rate for that zone restocks a location before it runs dry mid-wave, rather than after a picker is already standing in front of an empty bin — the same gap that turns an otherwise-clean wave into one still open when the next one releases.
Whether the wave ahead of it finished first
A late-running prior wave holds the labour and equipment a new release needs, so the delay carries straight into the next wave's window.
A new wave doesn't get pushed out while the previous one is still clearing the pack line, and waves are timed against each other rather than planned in isolation, so a release that slips early in the shift pushes the whole sequence behind it, not just the wave that actually ran late.
The task still open at the deadline is the one that matters.
Once your wave completion rate is read against a peer set matched on order profile, SKU count and footprint, the next question is which waves stalled and why — a release timed to a fixed clock instead of the zone's actual pace, a batch that was never going to clear in the window given, a pick face that ran dry mid-wave, or a prior wave still finishing when this one released. The same wave-open and wave-close events that build the figure trace back to the specific task still open when the window ran out, so the answer is a cause, not a shrug.
From there it's a scheduling change, not a bigger shift. Release timing, batch policy and replenishment sequencing already run together on the digital twin, so a different release trigger, a resized batch or a re-sequenced replenishment task can be tested against the same order mix already producing the current figure, before anything changes for a live wave. Once approved, the change reaches the WMS as the wave release rules, pick lists and replenishment tasks it already runs on.
- Wave completion rate read against a peer set matched on order profile, SKU count and footprint
- A stalled wave traced to the release, the batch, replenishment or the wave ahead of it
- Release, batch and replenishment changes tested on the digital twin before a live wave
Questions
What people ask about wave completion rate.
How is wave completion rate different from plan adherence?
A wave's window is fixed the moment it's released, and wave completion rate asks one thing inside that boundary: did every task inside the wave close before the window ran out? Picture a wave that tracked its plan closely for its entire run, pace holding steady zone by zone the whole way through, until a single pallet turned up short-picked right near the end and a supervisor had to force that one wave shut past its deadline. Nothing about the wave's pace ever looked wrong — plan adherence, tracked continuously, would have shown that same wave riding its plan the entire time — yet the wave itself still missed. That narrower, after-the-fact question is what this page answers, and it's plan adherence, reading pace across every zone for the length of the shift, that's worth checking whenever the concern is ongoing pace rather than one release's outcome.
Does a low completion rate mean the wave was overloaded?
Sometimes, but not always — a wave can carry a perfectly reasonable batch and still stall for reasons that have nothing to do with its size. A release timed to a fixed clock instead of the zone's actual pace, a pick face that ran dry mid-wave, or a prior wave still clearing when this one released can all leave tasks open at the deadline. Reading a stalled wave against its release timing, its batch and the wave ahead of it is what separates an overloaded wave from a badly timed one.
Shouldn't one target rate work for every wave?
A single target rate assumes every wave carries a comparable load, and that's rarely true even inside one warehouse, let alone across different operations. WareBee matches your operation on order profile, SKU count and footprint before it reads a single number, then checks your completion rate against operations releasing a genuinely similar batch of waves — the same clock and batch size would tell a very different story on a site running loosely grouped, single-order waves than it does on one running tightly consolidated ones.
What data does WareBee need to measure wave completion?
Wave release and wave-close events, alongside the pick, pack and replenishment task data your WMS already produces, are enough for a first read. Nothing needs new instrumenting — the same events that build the wave schedule in the first place are what let a stalled wave be traced back to the release, the batch or the replenishment gap that kept it open past its window.
Can WareBee tell which stage inside a wave is causing it to stall?
Yes. Because release, pick, pack, staging and replenishment are all logged as their own events, a wave that closes late can be traced to the specific stage still open when the window ran out, rather than left as one shift-wide impression that things felt slow. That's what turns a stalled wave into a cause you can act on instead of a number you just note and move past.
Does a corrected wave sequence reach the WMS?
Yes. Once a supervisor approves a different release trigger, a resized batch or a re-sequenced replenishment task, it goes out as the wave release rules, pick lists and replenishment tasks your WMS already runs on, so the change that closed the gap on the twin is the one the floor actually works to. Actuals flow back once the wave closes, so the next release starts from what genuinely happened rather than the assumption that left the last one open.