Fleet Telemetry Analysis on flespi: What Breaks at Scale

A fleet of two thousand GPS trackers. Last week roughly forty of them went dark. Which forty? Nobody can say without pulling an export, joining it against the device list and spending an afternoon in a spreadsheet. Meanwhile the vehicles behind those trackers keep driving, and every claim, dispute and compliance question that telemetry exists to answer now has a hole in it.

That's the recurring shape of fleet telemetry analysis at scale. flespi ingests and parses messages from hundreds of tracker models reliably. What degrades quietly is the operational health of the fleet: which devices report, which channels parse cleanly, which streams deliver. On fleets past a few hundred devices, nobody is watching all of it.

This guide maps the failure modes that matter: why each one happens, how to detect it today with a flespi panel path or a REST call, and what it typically costs a fleet operator. It assumes a flespi account and a token, ideally a read-only ACL token for anything you script.

This is part one of a three-part series. Part two is a hands-on guide to GPS fleet monitoring with flespi's native tools: panel, REST API, MQTT and analytics. Part three covers automating flespi fleet operations with an AI agent.

01Devices

Silent trackers

SIM, power or firmware failures that all look like the same silence.

02Channels

Parsing errors

Trackers that connect but send frames the channel rejects or misreads.

03Streams

Delivery backlog

Data that reached flespi but not the system your dispatchers read.

04Reports

Drift

Geofences and parameters that slowly stop matching reality.

05Cost

Retention

Proof-of-concept TTLs inherited by the production fleet.

The five failure modes this guide covers, each with a panel path or REST call to detect it today.

Why fleet health degrades without anyone noticing

flespi does its job well, and that's part of the problem. The platform ingests, parses, stores and forwards. It doesn't decide which of your trackers should be talking, so it can't tell you which ones stopped. Four structural reasons keep the gap open:

Silence isn't an event. A dead tracker produces nothing: no error, no log line, no alert. Absence only shows up when you go looking for it.
The failure surface multiplies. Every tracker model adds a protocol, every protocol is a channel, every firmware rollout can change the frames on that channel overnight.
Health lives in three places. flespi splits the pipeline into channels, devices and streams, and each one fails independently.
Thresholds don't fit fleets. "Offline after 6 hours" is right for a delivery van and wrong for a trailer tracker that reports twice a day.

01Ingest

Channels

One per protocol. Trackers connect here and frames get parsed into messages.

02Store

Devices

Each tracker’s messages and latest telemetry, kept for the TTL you set.

03Deliver

Streams

Forward messages to your backend, a TSP platform or a warehouse.

Three parts, three independent ways to fail. A fleet problem can start in any of them.

Start here: forty dark devices, worked through

Before the five failure modes, here's how to read the forty from the opening. The numbers are illustrative. Name the possible readings first, because each predicts different evidence:

01Reading 1

Parked

Ignition off, tracker asleep. Predicts a clean disconnect after an ignition-off message.

02Reading 2

Cellular

SIM, coverage or carrier. Predicts falling signal and short reconnects before the silence.

03Reading 3

Protocol

Firmware or channel mismatch. Predicts connections in the channel log but no new messages.

04Reading 4

Delivery

The tracker is fine. Predicts fresh telemetry in flespi and a stale map downstream.

Four readings of “these devices went dark”. Each predicts a different place in flespi where the evidence sits.

Step 1: which devices, and how long? Pull the last-message time for every device (the sweep in section 1 below). Forty-one devices are past 24 hours. Twenty-six went quiet on a Friday evening, which already leans toward reading 1.

Step 2: connected or not? Cross-reference the registry:

curl -s -H "Authorization: FlespiToken $TOKEN" \
  "https://flespi.io/gw/devices/all?fields=id,name,connected" \
  | jq '.result[] | select(.connected == true)'

Four of the silent devices still hold an open connection. A live socket with no messages is reading 3, so those four go to the channel log.

Step 3: same channel, same model? The four connected-but-silent devices are all on one Queclink channel. Its log shows repeated parsing errors starting two days ago, right after a firmware push. Reading 3, confirmed for four devices.

Step 4: what's left? Of the remaining eleven, the last messages before silence show signal levels falling and short reconnect bursts. Reading 2: SIM or coverage, a carrier ticket rather than a technician visit.

Conclusion. Forty-one "dark" devices turned into 26 parked vehicles, 4 firmware casualties on one channel and 11 cellular cases. Three different owners, three different fixes. The checks below are the raw material for that kind of triage.

1. Devices that silently stop reporting

What it is. The single most important health signal in any tracker fleet is last-message age: how long since each device produced a message. A tracker can die a dozen ways (SIM deactivated by the carrier, data plan exhausted, antenna damaged, firmware crash, power cut during a vehicle repair), and from the platform side every one of them looks the same: silence. flespi won't raise its hand for you. A device with no messages is simply a device with no messages.

Why it happens at scale. On 50 devices, a driver or dispatcher notices a stale dot on the map within hours. On 2,000, a silent device is statistically invisible, because the map still looks full. Silent-device counts in unmonitored fleets commonly drift to 2 to 5% before anyone runs a reconciliation, and each silent day means untracked mileage, unbillable data if you resell telemetry, and blind spots in driver-safety or ELD-style compliance reporting.

How to detect it. In the panel: Telematics hub → Devices, then sort or filter the grid by the last-message column and scan for stale timestamps. For anything scriptable, use the telemetry endpoint. Every telemetry parameter carries a value and a ts (when flespi received it), so the timestamp parameter tells you when each device last produced a message:

curl -s -H "Authorization: FlespiToken $TOKEN" \
  "https://flespi.io/gw/devices/all/telemetry/timestamp" \
  | jq --arg now "$(date +%s)" '
      .result[]
      | {id, last: (.telemetry.timestamp.ts // 0)}
      | .age_hours = ((($now | tonumber) - .last) / 3600 | floor)
      | select(.age_hours > 24)'

Anything over 24 hours for a vehicle that should be in service is a ticket. Anything over a week is probably a hardware or SIM problem, not a connectivity blip.

Typical impact. For operators billing per active device, silent devices are direct revenue leakage. For internal fleets they're compliance and dispute exposure. Either way, detection latency is the expensive part, not the failure itself.

2. Message drops and parsing errors on mixed tracker fleets

What it is. Real fleets are mixed: Teltonika here, Queclink there, a batch of Ruptela units from an acquisition, and a few no-name OEM trackers someone bought in 2021. In flespi, each protocol terminates in a channel, and channels are where parsing goes wrong. Devices connect to the wrong channel port, firmware updates shift a proprietary field, the protocol parser rejects malformed packets, or trackers misidentify themselves so their traffic never reaches the right device object.

Why it happens at scale. Every tracker model added multiplies the protocol surface. Firmware rollouts happen fleet-wide and without notice: the tracker updates itself overnight, and the first symptom is a parameter that stops arriving.

How to detect it. Open the channel in Telematics hub → Channels and check its Logs. Connection events, parsing errors and rejected frames are all recorded there per channel. Via REST:

curl -s -G -H "Authorization: FlespiToken $TOKEN" \
  "https://flespi.io/gw/channels/all/logs" \
  --data-urlencode 'data={"reverse":true,"count":100}' \
  | jq '.result[] | {channel_id, timestamp, source, event_code}'

Look for repeated error events concentrated on one channel or one device ident. That's your misbehaving tracker model. Cross-check volume too: a channel whose daily message count drops 30% while its device count holds steady is losing traffic somewhere.

Typical impact. Parsing failures are nastier than silence because the device looks alive. It connects and appears in logs while producing incomplete or zero usable messages. Trip reports and driver-behavior scores computed from partial data are worse than no data, because they're confidently wrong.

3. Stream backlogs and delivery failures

What it is. The flespi model has three moving parts: channels ingest, devices store and normalize, streams forward to your downstream systems (your own backend, a TSP platform, a data warehouse). Streams fail independently of ingestion. The destination endpoint times out, credentials rotate, a TLS certificate expires. flespi queues undelivered messages for a stream, but a queue is a debt. If the destination stays down long enough, your dispatch or billing system runs on stale data without knowing it.

How to detect it. Telematics hub → Streams shows each stream's state and queue in the panel. A queue that grows between two checks ten minutes apart means the destination isn't keeping up, or isn't accepting at all. Stream logs tell you why, with the same pattern as channel logs:

curl -s -G -H "Authorization: FlespiToken $TOKEN" \
  "https://flespi.io/gw/streams/all/logs" \
  --data-urlencode 'data={"reverse":true,"count":100}' | jq '.result[]'

Typical impact. Hours-long delivery gaps are common findings on a first audit. They surface downstream as "the map is frozen" support tickets that get misdiagnosed as tracker problems, which is reading 4 from the walkthrough above.

4. Geofence and parameter drift

What it is. Two slow-motion failure modes. First, geofence drift: depots move, customer sites change, and geofences defined in Telematics hub → Geofences two years ago no longer match reality, so entry and exit events fire wrongly or not at all. Every report built on them inherits the error. Second, parameter drift: the set of parameters a device sends changes over time (firmware updates add or rename fields, an installer wires an input differently), so a calculator or downstream report that depends on din, ignition or a fuel-level parameter silently reads nulls.

How to detect it. For parameter drift, list the current telemetry parameters of one device per tracker model and diff them against what your reports consume:

curl -s -H "Authorization: FlespiToken $TOKEN" \
  "https://flespi.io/gw/devices/1234567/telemetry/all" \
  | jq '.result[0].telemetry | keys'

If a parameter your trip logic depends on is missing for a whole model cohort, you've found drift. For geofences, nothing replaces a periodic review of the geofence list against current operational sites. Put it on the calendar quarterly.

Typical impact. Drift rarely breaks anything visibly. It degrades report accuracy month over month until someone disputes an invoice or a detention charge and the geofence evidence doesn't hold up.

5. Telemetry volume vs. retention cost

What it is. flespi bills around traffic and storage, and both scale with message frequency and retention. Every device and channel has a messages_ttl controlling how long messages persist. Defaults set during a proof of concept (high-frequency reporting, long TTLs, media such as photos and CAN dumps kept indefinitely) get inherited by the production fleet. Two thousand trackers at a 10-second reporting interval generate roughly 17 million messages a day. Keeping all of it for a year because nobody revisited a TTL is a cost decision made by default.

How to detect it. Inventory TTLs across the fleet:

curl -s -H "Authorization: FlespiToken $TOKEN" \
  "https://flespi.io/gw/devices/all?fields=id,name,messages_ttl,media_ttl" \
  | jq '.result | group_by(.messages_ttl) | map({ttl_seconds: .[0].messages_ttl, devices: length})'

Then ask the only question that matters: what's the longest lookback any report, dispute process or regulation actually requires? Everything beyond that is optional spend.

Typical impact. Retention rarely dominates a flespi bill, but on large fleets a TTL review typically trims a meaningful single-digit percentage, and it's a one-hour exercise.

Weekly export versus continuous detection

	Weekly export and spreadsheet	Continuous detection
Age of a finding	Up to a week, often more	Minutes to hours
Coverage	Last-message age, if that	Devices, channels, streams, drift, TTLs
Silence threshold	One number for the whole fleet	Each device's own reporting rhythm
"Why is it dark?"	An afternoon of clicking per batch	Readings checked before anyone looks
Owner of the result	Whoever has time that week	Routed to the team that can fix it

The checks are the same in both columns. What changes is how long a dead tracker stays dead before anyone with the right job knows about it.

Why the weekly export keeps failing you

Each check above takes minutes. The problem is arithmetic: five checks, times per-channel and per-model granularity, times a fleet that changes daily. A weekly export answers "which devices were silent as of last Tuesday". By the time anyone acts, the SIM has been dead for ten days and the customer has already called.

Fleet health isn't a report. It's a rate. Devices go silent continuously, firmware drifts continuously, streams back up at 2 a.m. The operators who stay ahead of it made detection continuous instead of calendar-driven.

Start by hand: part two of this series turns every check in this article into a repeatable workflow using only the flespi panel, REST API, MQTT and the analytics engine. Then part three shows CloudThinker connecting to flespi with a read-only token, watching the whole surface continuously, and working out why each device went dark, with every action starting in Manual and waiting for your approval.