Most cold chain monitoring programmes are judged on whether they produced a record. The more useful question is when the record arrived, and whether it arrived in a form somebody could act on.

That distinction rarely shows up in a procurement spreadsheet. It shows up at the receiving dock, when a temperature trace is read out of a logger and the interesting part turns out to have happened eleven days ago, somewhere between two terminals, with nobody in a position to intervene.

Regulators treat the record as something that drives decisions at several points, not only at the end. The EU’s Good Distribution Practice guidelines for medicinal products (2013/C 343/01, section 9.2) state that if a deviation such as a temperature excursion occurs during transportation, “this should be reported to the distributor and recipient of the affected medicinal products,” and that a procedure “should also be in place for investigating and handling temperature excursions.” The CDC’s Vaccine Storage and Handling Toolkit, in its section on storage and temperature monitoring equipment, is more operational: on discovering an excursion, staff label the exposed stock “DO NOT USE”, separate it from other stock, document the event, and contact the immunisation programme or manufacturer for a disposition decision.

Some of those decisions survive a delay — quarantine, stability assessment, corrective action. Others do not. Rerouting a truck or pulling a pallet before it goes back into a trailer is only available while the shipment is still moving. Late data narrows the menu without emptying it. A monitoring programme is worth roughly what it keeps open.

Where the latency actually comes from

Teams tend to blame connectivity. Connectivity is usually only one term in the sum. A practical decomposition of the delay between an event and someone acting on it looks like this:

Sampling interval. Nothing can be detected faster than the sensor reads. A device logging every 30 minutes may catch part of a 20-minute door event by coincidence, but it cannot reliably establish that the event happened, how long it lasted, or how far the temperature moved.

Storage versus transmission. Many devices log continuously but transmit on a much longer cycle, or only when a connection is available. The data exists the whole time. It is simply not anywhere useful yet.

Connectivity windows. A container stowed in a stack on a vessel, a trailer in an underground bay, a pallet inside a metal cage — all of them create stretches where a device has readings and no path out. Backlogged data eventually arrives in a burst, correctly timestamped, which flatters the record and obscures the fact that nobody could see it at the time.

Ingestion and rule evaluation. Platform-side batching, retries and alert thresholds add their own delay, often measured in minutes but occasionally in hours when a rule requires a sustained breach before it fires.

The human step. An alert that reaches a shared mailbox at 02:00 local time is not an alert. It is a message waiting for a shift change.

Add those together and a system described as “real-time” can produce its first actionable notification hours after the condition began — and on a deep-sea leg, sometimes not until the device regains cellular, satellite or gateway connectivity, which is a separate question from whether the reefer unit itself has been powered and running the whole voyage.

Latency is not one number, and the architecture decides which one you get

Three figures get conflated in most specifications, and they should be quoted separately.

Temporal resolution — how finely the record describes change over time. Set by the sampling interval.

Representativeness — how well the reading describes the thing you actually care about. Set by where the sensor sits relative to the cargo and the airflow.

Time to visibility — how long before the data is in front of a system or a person who can respond. Set by the transmission model and the connectivity available on the lane.

A carton-level BLE logger can have excellent temporal resolution and no remote visibility at all until a gateway comes into range. A cellular device reporting hourly may have coarse resolution and short time to visibility while it is in coverage. Neither is wrong. Problems start when a lane is designed around one figure and evaluated against another — which is how “we have full visibility” and “we found out at delivery” end up describing the same shipment.

An actionable record needs more than a temperature

Even data that arrives on time is not automatically usable. A disposition decision — release, quarantine, reject — tends to require four things at once:

– A defined measurement point. Return air, air at the door end, and product core are three different measurements. A number without a stated location cannot be compared to a specification that refers to product temperature.

– A shared time base. Temperature, location, door events and shock readings only tell a story together if they sit on the same clock. Reconciling three devices with three drifting clocks after the fact absorbs the hours you were trying to save.

– Identity that survives handling. The record has to be attributable to a specific pallet or carton, and that mapping has to hold through repacks and cross-docks. Otherwise the excursion is real but unassignable.

– Enough context to explain the reading. A spike that coincides with a logged door opening at a cross-dock is a different event from the same spike with no door activity, even though the trace looks identical.

Of the four, the measurement point is the one most likely to be settled at the loading dock rather than in the monitoring specification — and it constrains everything the record can support afterwards. A probe reading air in a free channel and a probe in the product core will disagree, and the disagreement is not an error. Eelink’s guide to reefer temperature probe placement sets out that trade-off against an integral container’s airflow, including why the door end is better treated as a defined risk location than as a guaranteed hot spot.

What to ask before the next lane goes live

Four questions surface most of the latency that specifications hide:

1. What is the sampling interval, and what is the transmission interval? If a vendor gives one number, ask which one it is.
2. On this specific lane, where does connectivity actually exist — and how long is the longest expected gap?
3. What is the measured time from threshold breach to a named person receiving something they can act on, including out of hours?
4. Where is the sensor, and against which specification is its reading being compared?

Answering them produces a service level rather than a feature list: an event-to-ingestion target, an ingestion-to-alert target and an alert-to-acknowledgement target, each with a number and an owner. It also forces an early decision about what the programme is for on a given lane — intervention while the goods move, disposition on arrival, or evidence for a claim. Those three imply different sampling intervals, sensor positions and reporting cadences, and they cost different amounts.

Answering these questions costs nothing but attention. Acting on the answers sometimes does mean different hardware — a shorter sampling interval, a second sensor position, gateway coverage at a transfer point. The useful shift is upstream of that purchase: a monitoring programme is a decision-support system with a response time, and it should be specified like one.