What
Picture the screen first. A movement-with-ignition-off alert fires at 02:14, but the position history behind it stops at a single fix. The vehicle is sitting in a covered ramp, so the tracker has gone quiet, and the normal cross-check cannot run yet. There is no clean displacement trail to measure and no second and third fix to compare against the ignition state. This is not a confirmed tow and it is not a false alarm. It is an open event, and the job is to hold it open honestly while you wait for buffered reporting to catch up. The mistake most teams make is closing it either way too early.A buffered log point is a position the device stored locally while it had no coverage, then pushed to the platform after reconnection. It normally carries a timestamp, coordinates, speed and heading. What it does not carry is proof that the whole journey was recorded. If the device drops points during the gap, you get a line that looks like a short hop when the vehicle actually travelled a kilometre. Treat a buffered point as a real observation at a real time, and nothing more than that.The alignment step is where late data gets misused. You match each late point against the original alert timestamp, the device ID and the ignition state at that moment, never against the time the upload landed. A point that uploads at 06:40 but is stamped 02:16 belongs to the 02:16 window. Line it up with the trigger, then ask whether the delay was small enough to preserve the default five to ten minute cross-check window you were working with. If the fixes slot back inside that window and show steady displacement with the ignition off, you have your tow. If the first valid fix after the trigger only appears thirty minutes later, the window is broken and the event stays unconfirmed until you can reconstruct it.Now the decision fork. Escalate immediately if the asset is high value, if the last known position sits in a high-risk area, or if any independent signal already agrees. A fuel level that fell with no engine hours and no ignition activity is a partial agreement, not a confirmation, but it is enough reason not to sit on the case. Hold the event open when the asset is low value, the location is a known dead zone, and no other signal leans either way. Holding is not the same as ignoring. Set a review point tied to when buffered uploads between-fixing-reconfiguring-or-replacing-a-failing-gps-collar-a19a7f" class="faq-link faq-link-internal auto-internal-link">should arrive, and let the event age visibly rather than disappear.Here is the field scenario most operators face. A van enters a covered ramp at 02:10. The trigger fires at 02:14 with position displacement and the ignition reading off, and then the device goes silent. Nothing transmits. Hours later the points reappear. Check in this order: confirm the device identity matches, confirm the buffered stamps sit after the trigger and before the next ignition-on event, measure displacement between those points, and read the fuel and engine hour figures across the same span. If the vehicle simply parked, the ignition will come back on before the next move and the picture clears itself. If it never does, and the displacement is steady and smooth, you are looking at a tow reconstructed after the fact.Separating a device that buffers correctly from one that discards data is harder than any spec sheet suggests. Do not trust the claim. Trust behaviour. Watch a vehicle you know entered a tunnel or a ramp. If the points that emerge line up into a continuous path with sensible spacing, retention is working. If you get one isolated fix and then a gap to the next stop, points were lost. Repeat that test across a few assets before you conclude the fleet, rather than the individual unit, is fine. Post-event reconstruction only works when the reporting layer keeps the logs long enough to rebuild them, so check retention before you need it, not during the case.A quiet tracker never means a stationary asset. A device in a dead zone reports nothing at all, including the tow, so silence is not evidence of safety. Finish every case with a short written record: trigger time, upload time, signals checked, classification, and whether the event was later confirmed or cleared. That single line is what stops fuel monitoring cost control from being built on a half-finished investigation, and it is what lets a team running vehicle tow detection at scale trust the queue again. When the same checklist runs across consistent vehicle telematics hardware, those records stay comparable, which is why standardising the device layer first makes everything downstream faster.