What
The cleanest way to settle this argument is to stop looking at the dashboard and start looking at the raw logs underneath it. Do that once, properly, and the decision usually makes itself. Pull a two-week export of telemetry from your fleet tracking platform. You want the timestamp of when the onboard unit captured each position, the timestamp of when the server received it, a signal strength or signal jitter indicator if your unit records one, every geofence entry and exit event, the polling interval setting as it stood during those weeks, and any network handoff records your provider can share. Two weeks matters because a single day of clean data tells you nothing. You need normal service days, peak shift changes, and known trouble zones in the same sample, which for most depots means metal-roofed parking bays, tunnels, and dense urban corridors.Then work through the export line by line. Subtract the onboard capture time from the server receive time for each point. That number is your delay. Flag every update where the delay crosses one second. Count how many flagged updates you get as a share of total points. Then pull the geofence events and see whether entry and exit timestamps line up with the delay pattern. Here is where a lot of people get surprised: a system designed to buffer location data so the map looks smooth will hide that delay from you until a weekly compliance report quietly shows a chunk of trips missing geofence entry timestamps. In my experience reviewing these reports, seeing roughly fifteen percent of trips without a clean entry stamp is a signal that buffering is masking real latency, not that buses failed to arrive.Now segment the results. Break flagged updates down depot by depot and route zone by route zone. If delay is spread fairly evenly across zones and climbs during certain hours, the finger points at network handoffs or a polling interval that is too slow for the traffic volume at that moment. Urban corridors with tall buildings reflecting signals, and cellular handoffs between towers, are common culprits. If instead the delay clusters tightly at specific sites, appearing every single day at the same bay or the same tunnel approach, that is onboard lock failure. Signal jitter in a tunnel can make the system log a stationary bus for ninety seconds, which skews arrival predictions and triggers idle engine penalties nobody earned.With that pattern in hand, your decision path is short. Widespread delay across all zones and times means tune the polling interval to match depot traffic volume, then reconfigure your geofence alert thresholds to account for expected drift. Give it a few weeks and re-audit. Repeated lock loss at specific sites means the hardware itself cannot hold a consistent fix in those conditions, and no polling change will fix physics. As an observed decision boundary rather than a universal rule, if more than roughly eight percent of location updates still show delay above one second across every operational zone after you have tuned and reconfigured, replacing the vehicle telematics units deserves serious weight. A useful middle step: a GPS Controller platform that exposes raw telemetry latency lets you audit timestamps against recorded signal strength directly, so you can judge whether reconfiguration is enough without tearing out a working system.One more thing worth doing properly. Keep the audit itself as a document. Attach the export, the flag counts, the depot comparison, and the before-and-after numbers. That record is what turns a replacement request into a defensible decision instead of a hunch, and it is also what protects your bus tracking ROI planning from repeating the same latency mistake with new hardware. Scale matters here, too. A fleet of two hundred buses produces around twenty thousand location points every hour, and a delay of just three seconds per point adds up to a sixteen-minute drift in aggregate route optimization over a day. That drift is enough to send buses into congestion the plan was never prepared for. Start with the cheap fixes, audit honestly, and let the logs tell you when the cord needs cutting.