Start with the condition the system actually reports
An alert named unplugged can sound like a complete explanation. Before treating it as proof that someone removed a tracker, ask what observation produced that label. Was it a supported external-power event, a status derived after reconnection or an absence of recent communication? Those are different forms of evidence, even if the screen uses a short familiar name.
Use this review when comparing a fleet proposal or agreeing an exception-handling process. Keep three questions separate: what the device recorded, when the platform received it and what a responsible person independently confirmed. An event label alone should not become a conclusion about a driver.
Confirm the exact vehicle and device setup
Record the proposed device model, vehicle group and approved connection arrangement. Ask the provider which power-related fields or events are supported for that combination and whether the required configuration is included. Do not infer a removal alert from the presence of an OBD-II connector, a battery specification or a general tracking feature.
Samsara defines its own VG Unplugged health reason in terms of the gateway not receiving power. This is a vendor-specific status definition, not evidence that a named person physically removed a device. Ask for the actual definition used in the system being demonstrated rather than transfer another provider’s labels or thresholds.
Separate event time from notification time
Ask the presenter to identify the event timestamp, time zone, receipt time and notification record where each is available. If a report becomes visible after power or communications return, record that limitation beside the evidence. A later notification does not by itself establish that the underlying condition started at the same moment.
Geotab explains that its unplug report can become available after a device is connected again and says that its records do not establish intentional unplugging. That example supports checking the reporting sequence. It does not establish SafarTrak event logic, backup operation or delivery timing. Keep unavailable timestamps unresolved.
Review context before deciding the cause
Check approved workshop work, planned vehicle isolation and the responsible team’s inspection record where relevant. Ask whether an installation or power-supply issue still needs investigation. Keep an explanation separate from a verified finding; a power-related status does not identify a person or establish theft, tampering or misconduct.
Preserve the original event reference and the exact information available at the time of review. Record what was demonstrated, what was unsupported and which question remains open. If a record only establishes missing communication, do not relabel it as a confirmed power-loss event.
Use a safe demonstration and define the response
Begin with an approved recorded example. If a separate physical test is necessary, the provider and qualified responsible team should agree it under the applicable installation and vehicle instructions. This checklist does not instruct anyone to disconnect vehicle wiring, operate on a moving vehicle, interfere with safety equipment or change live reporting settings.
Agree who reviews the evidence, who checks the vehicle and how the result returns to the fleet team. Ask the provider to demonstrate the supported notification and recovery sequence instead of promising that every interruption produces an immediate message. The blank worksheet keeps condition, event time, receipt time, notification evidence and confirmed cause in separate fields.
Bring the unresolved question to the SafarTrak discussion
SafarTrak’s public ST200 page describes temporary operation from backup power when vehicle power is interrupted. That statement does not establish an unplug-alert feature, a guaranteed runtime or delivery during every outage. Ask the team to demonstrate the actual event and reporting evidence supported for your proposed vehicle and device setup.
Use the wired-versus-OBD article for the wider installation choice and the parked-vehicle article for reporting expectations while a vehicle stands unused. This checklist addresses a narrower acceptance question: can the proposed workflow distinguish a recorded condition from an assumption about removal, and show what happens before and after reconnection?
Sources and further reading
This buyer checklist does not establish that a tracker was removed, who handled it or why. Vendor examples describe their own hardware. Confirm the supported evidence and notification workflow for the proposed SafarTrak setup.
BRING IT TO YOUR FLEET
Start with your vehicles.
Ask the right questions.
Share your vehicle mix, existing devices and required signals with the SafarTrak team.
Discuss supported device evidenceDiscuss your deployment
