A missing tracker signal is not a missing asset

A dot that stops moving tells three different stories

Say the rule is simple: every vehicle is inside the depot geofence by 21:00. At 21:10, one vehicle shows a last-known position just inside the fence, recorded twenty minutes ago, and nothing since.

Three very different things could be happening. The vehicle left after that position was captured. The tracker lost power or network coverage. Or the device is awake but local conditions are degrading its reports. Each possibility points to a different team, and only one of them is an operational incident.

Treating every gap as a confirmed departure floods the operations desk with escalations that turn out to be equipment noise. Treating silence as proof that everything is fine is more dangerous, because it creates a monitoring gap nobody notices until the night it matters. Vehicles are not the only case. A cold-storage door sensor that stops reporting tells you nothing about the door it can no longer see, and a temperature feed that goes quiet says nothing about whether the freezer is holding its setpoint.

A monitoring setup earns its keep by doing more than raising an alert. It should help the person on duty answer three questions:

• What do we actually know, and how fresh is that knowledge?
• What could explain the missing observation?
• Who needs to investigate, and what evidence will they need?

What each signal can and cannot prove

Every telemetry message is evidence about one moment. It does not automatically prove everything you would like to know. That single principle prevents most bad interpretations, so it is worth being precise about what common signals mean.

• A geofence exit with a timestamp is strong evidence of a departure. It says the device was at a boundary, at a specific time, and crossed it.
• A last-known position is evidence about the past. Displaying it prominently can quietly mislead, because a stale dot looks identical to a live one unless the map shows its age and source clearly.
• A heartbeat, the regular I-am-working message a device sends, proves communication. It does not prove location, and it does not prove that the sensing function feeding the report is healthy.
• A delayed message can accurately describe an earlier event while saying nothing about the present. Keep the device's event time and the server's receive time separate, or a message that arrives late will be read as news.

One more piece of context matters: which device was on which asset at the time. Trackers get swapped between vehicles and sites. When they do, keep the pairing history, so an event from last month is interpreted against the equipment relationship that applied then, not the one on record today.

Classify the gap instead of guessing

With those distinctions in hand, a missing observation falls into one of three situations, and each deserves its own treatment.

A fresh observation exists

If a current position or sensor reading arrived minutes ago, presence is confirmed for that moment. Answer the immediate question, and let unrelated alarms stay open for their own review. One clean signal should not paper over a different anomaly.

The device is reporting, but the expected observation is missing

Say the tracker is still sending heartbeats and even positions, but the vehicle is not where the rule expects it. The honest output is closer to a statement than a verdict: the expected presence is no longer confirmed, the device is reporting normally, the last position is here at this time, and no scheduled job or authorized movement explains the gap, so investigate.

Look for corroboration, such as a recent outdoor position moving away from the site. But stay careful. Healthy communications prove the radio link works, not that every sensing function works. A detection fault remains a live possibility until someone checks.

The device has gone silent

When a device stops providing usable information, classify the situation as monitoring uncertainty, and treat that classification as real. Carrying the previous state forward indefinitely conceals the gap. Silence also needs its own trigger, because a rule that only evaluates when a packet arrives will never fire once packets stop. The check for no data within a set number of minutes has to run on the server, on a timer, independent of the device.

The distinction worth protecting is the one between absence of evidence and evidence of absence. A missing signal is not a fact. It is a question, and the monitoring system's job is to frame that question well.

Send each exception to the people equipped for it

A classified exception is only useful if it reaches the right desk with the right evidence attached. Operations and support need different things.

• The operations team needs the operational picture: last position and its timestamp, the rule or schedule in play, whether any authorized movement applies, and a plain statement of what is known and what is missing.
• The support or technical team needs the equipment picture: last communication time, power events, device status, and installation details such as where the unit is mounted and what it is paired with.

Two habits keep these handoffs honest. First, distinguish observed conditions from suspected causes. A power-loss event followed by silence suggests a drained backup battery, it does not prove one. Second, define closure conditions for each incident type. Renewed communication is one recovery milestone; a usable observation from the correct device is another. A tamper or disturbance flag may still need review after reporting resumes. Keep the recovery timeline, so both teams share one account of what returned to normal and what did not.

On authorized movement, let the source of truth stay the source of truth. If dispatch records say a vehicle is booked for a night job, the monitoring workflow should use that as context, with its validity window, and not quietly become the authority on permission itself.

How this looks in RAAD

RAAD is built around exactly this problem: one console where tracking, power, cameras, locks, sensors and paperwork live on one map, on the hardware you already run. A few pieces do the work when a signal goes missing.

• Track keeps geofences, rules and trip history together, so a confirmed boundary exit and a communication loss arrive as separate, timestamped events rather than one ambiguous alarm.
• AI Insights reads every alert and holds back what does not need a person, then brings the rest with a reason and a proposed fix. A silent device is triaged with its evidence attached instead of being forced into false certainty, and nothing touches a vehicle until someone approves it.
• Assets and Maintenance keep asset records and inspection reminders alongside the tracker data, so an exception can be read against the equipment that produced it.
• Per-screen roles mean the operations desk and the support team each see the view built for their job, without a shared wall of noise.

For partners reselling RAAD under their own brand, the payoff is quieter support queues: fewer tickets that turn out to be equipment noise, and a cleaner story about alert quality under their own logo.

Measure the workflow, not the alert count

Before trusting any of this, decide how you will know it worked. Alert volume alone will not tell you.

Record what investigators actually found after each exception. Useful categories are simple: authorized movement, confirmed equipment fault, detection difficulty, unresolved cause. Combine those outcomes with acknowledgment and resolution times, and you can see which conditions repeatedly create work and whether context is genuinely shortening investigations.

Worth watching: minutes of monitoring uncertainty, repeat equipment incidents on the same asset, and time to restore usable observations.

A falling alert count is ambiguous. It can mean the workflow is triaging well, or that the system has stopped surfacing events that matter. Judge workload and monitoring quality together, or you will not know which one you have.

Test the whole path before you trust it

Finally, test the complete path from physical condition to resolved incident before going live, using real devices on real assets:

• detection loss, power failure, communications loss and restoration;
• stale values, delayed messages and duplicates;
• device swaps between assets, and reassignment;
• schedule changes and expired authorizations;
• timeouts in the case where no telemetry arrives at all;
• incident delivery, acknowledgment, escalation and closure.

The goal throughout is to give the right people better evidence, faster, while keeping the limits of that evidence visible. A missing signal is a question. A well-built monitoring operation answers it with evidence, routes it to the desk that can act, and never mistakes silence for safety.