A shipment has produced no scan events for eighteen hours. Is that a problem?

Silence means different things at different points

Eighteen hours with no scan on a trunk movement between two depots four hundred miles apart is exactly what should happen: the vehicle departed, it will arrive, and nothing emits an event in between. Eighteen hours between "arrived at delivery depot" and "out for delivery" means the parcel is sitting in a building and nobody has looked at it.

So a single global rule — alert if nothing has been seen for N hours — is wrong in both directions at once. It floods the queue with line hauls that are fine and stays silent on the parcel that has genuinely been lost in a depot.

The design that works inverts the question. Rather than measuring time since the last event, each milestone declares what should happen next and by when.

current milestone            expected next                    deadline
Manifested at origin         Departed origin                  4 hours
Departed origin              Arrived at destination depot     transit time + 6h
Arrived at destination depot Out for delivery                 next working day 10:00
Out for delivery             Delivered or attempt failed      end of day
Attempt failed               Out for delivery again           2 working days
Returned to depot            Out for delivery or to sender    3 working days

Now eighteen hours is checked against the row the shipment is actually on, and the same silence is fine in one and an exception in another.

Alerting on something that did not happen

The mechanical difficulty is that a missing event emits nothing. Every other alert in your system fires because something occurred; this one has to fire because nothing did.

Two workable shapes. A scheduled sweep queries for shipments whose expected deadline has passed without the expected event and raises exceptions — simple, easy to reason about, and its resolution is the sweep interval. A timer per shipment, set when the milestone is reached and cancelled when the expected event arrives, fires precisely and requires durable scheduling because a restarted process must not lose a million pending timers.

Most operations use the sweep, because the resolution needed is minutes rather than seconds and because a table scan over open shipments is cheap next to the alternative.

Either way, the deadline is not a constant. It varies by lane, by service level, by carrier and by whether tomorrow is a public holiday in the destination country. Hard-coding "4 hours" produces a system that is wrong every bank holiday, which is how operations teams learn to ignore an alert queue.

Distinguish a stalled shipment from a broken feed

The failure that discredits an exception system fastest: the carrier's status feed stops, every shipment on that carrier breaches its deadline simultaneously, and ten thousand exceptions arrive at once for parcels that are moving perfectly well.

The defence is to monitor the feed as a thing in its own right, separately from the shipments. If the volume of events from a carrier drops far below what that hour of that weekday normally produces, that is one alert about an integration, and shipment-level exceptions for that carrier should be suppressed while it holds.

The general principle is worth stating in an interview: an exception system needs to know the difference between "the world went wrong" and "we stopped hearing about the world", because the response to each is completely different and the symptom is identical.

Hand-offs are where things are lost

Ask where in a journey shipments actually disappear and the answer is consistently at the boundary between two parties: origin carrier to line haul, line haul to final-mile partner, partner to a locker network. Inside one organisation's operation the tracking is usually decent; across the seam, each side believes the other has it.

The engineering that addresses this is to model the hand-off as an event with two sides — dispatched by A, received by B — and to treat a dispatch with no matching receipt as its own exception category. A single "in transit" status spanning the boundary hides exactly the gap you need to see.

This is the same distinction that matters in EDI acknowledgements, where a file being parsed successfully and a carrier accepting the load are two separate facts, and treating the first as the second produces a shipment everybody believes is booked and nobody has collected.

An exception nobody can act on is noise

The last part, and the one that separates a design from a dashboard. Every exception category needs a named owner and an action available to them.

"Parcel silent for eighteen hours in a depot" is actionable: a control-tower analyst can call the depot and have someone look on the floor. "Parcel silent during line haul" is not, at 2am, by anyone — so it should not page. And the customer-facing consequence has to be decided deliberately: proactively telling someone their delivery is delayed is usually better than letting them discover it, but only once you are confident enough not to send it for every feed hiccup.

The metric that keeps the system honest is age of open exceptions, not their count. A queue with two hundred exceptions all under an hour old is a healthy operation working; twenty exceptions averaging four days old is a queue nobody is clearing, and that is the number a control tower should be judged on.

Do not alert on time since the last event. Alert on the event that should have happened by now, because the same eighteen hours of silence is routine in one place and a lost parcel in another.