How a Vehicle Traveling at 3,220 km/h Broke Our Fleet Tracking — and What We Built to Fix It

By Carlos Alberto Peña Molina — Founder & AI Systems Architect, Runox

One morning, the live operations dashboard for our field service platform showed something impossible: a vehicle traveling at 3,220 km/h.

No, it wasn’t a typo. And no, we hadn’t accidentally built a rocket into our scheduling software.

What we had discovered — the hard way, in production, on a real route — was one of the most under-documented failure modes in mobile GPS development: GPS teleportation. And fixing it properly took weeks of architectural work that fundamentally changed how we think about location data in field service operations.

This is the full story of what happened, why standard approaches fail, and the multi-layer system we built to solve it.

The Incident

We were running the Runox platform in live operations — a field service management SaaS built for cleaning and home service businesses. One of our vehicles went stationary on a job site. Normal. The app registered it as IDLE, the GPS chip entered low-power mode, and the phone’s OS began throttling location updates to preserve battery.

So far, textbook behavior.

Then the technician got back in the vehicle to head to the next job. The phone’s GPS chip attempted to reacquire satellite lock after being in low-power mode for 15+ minutes. During those first few seconds of reacquisition, the chip emitted a sequence of coordinates that were wildly inaccurate — some up to several kilometers away from the actual position.

Our backend faithfully ingested those coordinates, calculated the implied speed between the last stored position and the new one, and displayed the result: 3,220 km/h.

The vehicle appeared to have teleported.

On the dashboard, the technician’s dot jumped across the map. Our fleet status panel showed “Moving” with an absurd speed. The operations manager called us. We had a problem.

Why This Happens (and Why It’s Harder Than It Looks)

GPS teleportation is a well-known phenomenon, but most resources treat it as a simple outlier filtering problem: “just reject coordinates that imply impossible speeds.”

That advice is correct but incomplete. In field service operations, it leads directly into a second failure mode that’s arguably worse than the original.

Here’s the trap:

When a phone’s GPS is in IDLE mode — parked on a job site — the chip provides very coarse location updates. The OS applies aggressive accuracy thresholds. In practice, for a stationary vehicle, 11 out of 12 GPS pings can be rejected by a strict accuracy filter because they don’t meet the required precision threshold.

So you implement the obvious fix: tighten your accuracy threshold, reject low-quality signals. Result? You stop the teleportation. But now your vehicle appears frozen on the map for 15+ minutes, because almost every incoming ping gets filtered out.

You’ve traded a vehicle that teleports for a vehicle that disappears. Neither is acceptable in a live operations dashboard where a dispatcher needs to know where their team actually is.

The fundamental tension is this:

• During navigation, you need strict accuracy (±50m) to show meaningful movement.
• During idle/parked states, you need to relax thresholds substantially (±700–1000m) or you’ll filter out the only signals the chip can produce.
• During the transition between these states, you need to handle the GPS reacquisition burst without creating phantom jumps.

No single threshold setting handles all three scenarios correctly. You need a context-aware, state-machine-driven approach.

The Architecture We Built

After the incident, we designed a four-component system. Each component addresses a different failure mode.

Component 1: The GPS Mode State Machine

We formalized four distinct operating modes for every tracked device:

ModeTriggerAccuracy ThresholdDescriptionIDLEVehicle stationary, no active shift700–1000mCoarse, battery-preservingSHIFTShift started, vehicle about to move25–100mWarm GPS, pre-navigationNAVIGATIONVehicle actively moving50mFull precisionONSITEVehicle stopped at service location70mModerate, geofence-aware

The key insight is the SHIFT mode — a warm-up state between IDLE and NAVIGATION that we built inspired by how Uber and Lyft handle driver state transitions. When a technician starts their shift (taps "Start Route" in the app), we don't immediately switch to full NAVIGATION mode. Instead, we enter SHIFT mode:

• preventSuspend: true — prevents the OS from throttling the GPS process
• stationaryRadius: 25m — tight geofence to detect movement intent
• stopTimeout: 15min — generous timeout before reverting to IDLE

This gives the GPS chip time to warm up and acquire accurate satellite lock before we start trusting its output for position calculations. By the time the vehicle actually pulls out of the driveway, the chip is already locked and producing clean signals.

Component 2: DB-Backed Anti-Teleport Filter

The original anti-teleport logic lived in memory — a simple variable holding the last known good position. This had a critical flaw: if the app restarted, that variable reset to null, and the first new position after restart would always pass the filter regardless of how far it was from the previous stored position.

We moved the validation to the database.

Every incoming location ping is now validated against the last persisted position for that vehicle in Supabase before it gets written. The validation logic:

-- Pseudo-logic for the Edge Function validation
last_position = SELECT lat, lng, recorded_at 
                FROM vehicle_live_locations 
                WHERE vehicle_id = $1 
                ORDER BY recorded_at DESC 
                LIMIT 1;

distance_km = haversine(last_position, incoming_position);
time_delta_hours = (incoming.recorded_at - last_position.recorded_at) / 3600;
implied_speed_kmh = distance_km / time_delta_hours;

IF implied_speed_kmh > 200 THEN
  -- Log to gps_audit_events, reject ping, do not update position
  RETURN 'REJECTED_TELEPORT';
END IF;

The 200 km/h threshold was chosen deliberately — it’s above any realistic speed a field service vehicle would travel (our market is urban and suburban routes), but safely below the 3,220 km/h anomalies we were seeing. Any implied speed above 200 km/h gets rejected and logged.

The key difference from in-memory validation: this check works correctly even after app restarts, device reboots, or backend Edge Function cold starts. The ground truth always comes from the database.

Component 3: Intelligent Accuracy Filter

The accuracy threshold is now dynamic, driven by the current GPS mode:

function getAccuracyThreshold(mode: GPSMode): number {
  switch (mode) {
    case 'NAVIGATION': return 50;   // meters — strict
    case 'ONSITE':     return 70;   // meters — slightly relaxed
    case 'SHIFT':      return 100;  // meters — warming up
    case 'IDLE':       return 1000; // meters — coarse, battery-first
  }
}

During IDLE, we accept signals up to 1000m accuracy because that’s the reality of what a parked phone produces, and we need some position to show the dispatcher. During NAVIGATION, we hold to 50m because that’s when precision actually matters for route tracking.

This single change — making the threshold contextual rather than static — eliminated the “frozen vehicle” problem that plagued our first fix attempt.

Component 4: GPS Audit System

The final component is observability. We created a gps_audit_events table that logs every significant GPS event with a 90-day retention window:

CREATE TABLE gps_audit_events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  vehicle_id UUID REFERENCES vehicles(id),
  event_type TEXT CHECK (event_type IN (
    'signal_lost', 
    'reactivated', 
    'mode_change', 
    'geofence_exit', 
    'geofence_enter',
    'rejected_teleport',
    'rejected_accuracy'
  )),
  previous_mode TEXT,
  new_mode TEXT,
  lat DECIMAL,
  lng DECIMAL,
  accuracy_meters DECIMAL,
  implied_speed_kmh DECIMAL,
  recorded_at TIMESTAMPTZ DEFAULT NOW()
);

This table serves two purposes. First, it gives operations managers a real-time view of fleet GPS health — we surface alerts in the Live Ops dashboard when a vehicle has been in signal_lost status for more than 5 minutes. Second, it gives us the data we need to tune the system over time. We can see exactly which routes, which devices, and which conditions produce the most rejected pings.

The Results

After deploying all four components, we re-ran the problematic route — the same highway (US-41 in Southwest Florida) at the same speed range (60–65 km/h) where the original teleportation incident had occurred.

Before: 11 out of 12 IDLE-state signals rejected, position effectively frozen. Reactivation after idle produced 3,220 km/h phantom jump.

After: Signal acceptance rate improved 7.5x. Continuous tracking on US-41 at 60–65 km/h with position accuracy within 2 meters. Zero teleportation events in subsequent production monitoring.

The SHIFT mode warm-up period proved to be the highest-impact single change. By the time drivers actually start moving, the GPS chip has already been in active-acquisition mode for enough time to have clean satellite lock. The transition from parked to moving no longer produces a burst of bad data.

What This Taught Me About Production GPS

A few things I wish I had known before building this:

1. GPS is a state machine, not a stream. Most location tracking tutorials treat GPS as a continuous stream of coordinates to be filtered. In practice, the chip transitions through discrete power states, and each state has fundamentally different signal characteristics. You need to model those states explicitly.

2. In-memory validation doesn’t survive the real world. Apps restart. Phones reboot. Background processes get killed. Any validation logic that relies on in-memory state will have blind spots. Persist your last-known-good position in a database and validate against that.

3. The “freeze or teleport” tradeoff is false. The naive framing is that you have to choose between showing a frozen vehicle (tight filter) or a teleporting one (loose filter). The actual solution is a context-aware filter that’s tight when you need precision and relaxed when you’re parked. The GPS mode state machine resolves the apparent dilemma.

4. You need observability before you can tune. We couldn’t have designed the right thresholds without the audit log data from real routes. Build the observability layer first; the tuning comes second.

Why This Matters for Field Service Platforms

The cleaning and home services industry in the United States is highly fragmented — there are hundreds of thousands of small and mid-size operators who have never had access to real-time fleet visibility. They manage routes by phone calls and text messages. When a technician is late, the dispatcher calls to ask where they are.

Fixing GPS reliability isn’t just a technical problem. It’s the difference between a platform that operators can actually trust for live dispatch — and one they’ll abandon the first time it shows a vehicle in the wrong place.

The system described here is now running in production at Runox, handling real routes for real field service teams. If you’re building location-aware software for mobile workers and want to go deeper on any of these components, reach out.

Carlos Alberto Peña Molina is the founder and AI Systems Architect of Runox, a field service management platform built for cleaning and home service businesses. Runox is built on Supabase, React, and Capacitor with native Android GPS.

Connect on LinkedIn: linkedin.com/in/carlos-alberto-pena-molina-344475264