It was 2:17am. A vehicle from a logistics fleet in Lagos went off-route on a highway known for carjackings. The operations manager found out at 8:45am — when a driver called to say the truck was missing. The tracking platform had been down for maintenance since 1am. There was no alert, no fallback, no audit trail. Just a seven-hour gap in the logs and a truck that had already been stripped.
The platform vendor's response: a support ticket acknowledgement and a note that maintenance windows are listed in the terms of service.
This is a real category of incident. It doesn't make the press. It doesn't show up in fleet software comparison guides. It doesn't appear in the ROI calculators vendors put on their websites. And it is happening to fleets somewhere, every single week.
The reliability problem that nobody in fleet software talks about
Fleet management software vendors compete on features. The sales deck covers real-time tracking, driver scoring, fuel monitoring, ELD integration, dashcam support, AI alerts. Nobody leads with uptime. Nobody competes on reliability. Most vendors don't even publish their uptime history publicly.
There are two reasons for this. The first is that legacy fleet software was built on legacy infrastructure — on-premise servers, single-region cloud deployments, monolithic databases that need scheduled maintenance windows to stay healthy. Downtime isn't a failure mode for these platforms. It's a design feature. The maintenance window is in the contract.
The second reason is that fleet managers, historically, accepted it. If tracking goes down at 2am and the fleet manager finds out at 8am, the implicit assumption has been: well, not much happens at 2am anyway. This assumption is wrong, and getting more wrong every year as fleets operate around the clock, cross more borders, and carry higher-value cargo.
What actually happens when fleet software goes down
The naive version of a tracking outage is: the map goes blank for a few hours, then comes back. Nobody notices. No harm done. This version does not describe what actually happens in a production fleet environment.
Theft and unauthorised use become invisible
The primary value proposition of GPS tracking is theft detection and after-hours alert. A vehicle that leaves the yard at 1:30am triggers an alert — but only if the platform is up. During a maintenance window, that alert never fires. The geofence never trips. The ignition-on event lands in a queue that nobody is watching. By the time the platform recovers, the vehicle is somewhere else and the trail is cold.
This is not a hypothetical. Industry estimates put after-hours unauthorised vehicle use at 3–8% of commercial fleet vehicles globally. The incidents that happen during outages are simply never attributed to the outage — they're attributed to the theft or the driver, which is fair, but they were preventable.
Compliance logs develop gaps that don't close
Regulatory compliance in fleet operations — AIS-140 in India, RTA mandates in the UAE, FMCSA HOS records in the US, tachograph requirements in Europe — depends on continuous, tamper-proof telematics logs. A four-hour outage in the middle of a long-haul run is not a four-hour gap that gets reconstructed later. It's a permanent void in the compliance record.
For most fleets this creates a low-grade, continuous compliance risk: the logs exist, mostly, but an auditor who pulls records for a specific date range and finds gaps will ask questions that have no good answer. “Our platform was down” is not a defence. It's an admission that the compliance system is fragile.
Incidents during outages have no evidence
Accidents happen. When they happen during a tracking outage, the telematics record — the one that would show speed at impact, braking pattern, location, and context — doesn't exist. The driver's account is the only account. Insurance claims become disputes. Disputes become legal costs. Legal costs are a direct line item to the fleet's P&L that nobody traces back to a four-hour maintenance window three months earlier.
Dispatchers operate blind at the worst possible times
Outages don't respect shift schedules. When tracking goes down at 11pm before a peak delivery day — the kind of night when an e-commerce warehouse is funnelling its highest-value loads — dispatchers lose visibility across the entire fleet simultaneously. Every question a customer asks gets answered with a shrug. Every ETL that was automated becomes a phone call. Every exception that would have been caught automatically gets missed.
How to read a vendor's reliability claims
Most fleet software vendors will tell you they have “high availability” or “enterprise-grade infrastructure” if you ask. Almost none publish a public status page. Here is what to look for — and what each indicator actually means.
A public, historical status page
The gold standard for transparency is a public status page that shows not just current system health but historical uptime — incident by incident, with resolution times and root cause notes. A vendor willing to publish this is a vendor whose reliability can be verified. A vendor without one is asking you to take their word for it.
The difference matters because stated uptime and actual uptime diverge. A vendor can claim 99.9% uptime while defining “downtime” in a way that excludes maintenance windows, partial outages, and degraded performance. A public historical log with timestamps can't be gamed the same way.
The difference between 99%, 99.5%, and 99.9%
These numbers sound similar. They are not.
99% uptime means roughly 87 hours of downtime per year — more than three and a half days. A platform running at 99% is down, on average, for a full week every 12 months. Spread across the year, that's about 1.5 hours of downtime every week. For a 24/7 fleet operation, this is not acceptable.
99.5% uptime means roughly 44 hours per year — less than two days, but still two days. Still one or two hours of downtime per week on average.
99.9% uptime means roughly 8.7 hours per year. About 10 minutes per week. This is the threshold at which most fleet operations stop experiencing meaningful tracking gaps from platform downtime alone.
99.7% — where ViaLoop Fleet currently sits by SLA — is roughly 26 hours of allowed downtime per year, or about 30 minutes per week. More importantly, individual incidents are monitored and published; the SLA is a ceiling, not an average.
Maintenance windows: the hidden downtime
Traditional fleet software is built on infrastructure that requires scheduled maintenance to remain stable. Database vacuums. Index rebuilds. Certificate rotations. Software patches. The classic approach is a 2–4 hour maintenance window, usually scheduled between midnight and 4am, usually disclosed in the terms of service in a way that makes it easy to miss.
Modern infrastructure — zero-downtime deployments, rolling updates, database migrations without table locks, blue-green release patterns — makes maintenance windows unnecessary. They're not a given. They're a choice, made by vendors who haven't invested in the underlying engineering to avoid them.
What a reliability-first architecture actually looks like
The technical choices that produce reliable fleet software are not mysteries. They are expensive to build and require engineering discipline to maintain — which is why most fleet software vendors haven't done it.
Multi-region redundancy
A platform running on a single cloud region goes down when that region has an incident. This happens. Every major cloud provider — AWS, GCP, Azure — has had regional outages in the last five years. A platform that fails over between regions automatically never shows that failure to the fleet manager. To them, the map just keeps working.
Real-time monitoring on every feature, not just the homepage
Most monitoring setups check whether the platform is “up” — whether the homepage loads and the API responds. This is not sufficient. A fleet management platform can be “up” by that definition while geofence alerts have silently stopped firing, while driver scores have stopped updating, while the map has stopped refreshing live data.
Proper monitoring instruments every user-facing feature independently — live location update latency, alert delivery time from event to notification, report generation time, API response time per endpoint — and alerts the engineering team the moment any of them degrade, not when a user files a support ticket.
Store-and-forward on the device
Reliability is not just a server-side problem. GPS devices that lose connectivity should buffer events locally and sync them when the connection returns. A device that drops events during a cellular dead zone produces the same compliance gap as a server outage. Store-and-forward — where the device queues events and pushes them in order on reconnection — closes this gap regardless of whether the outage was on the server side or the network side.
How to evaluate your current platform's reliability
Four questions worth answering before your next contract renewal:
Does your vendor have a public status page? Not a contact-us-for-status page. A live, public, historical dashboard. If not, ask them to send you their uptime report for the last 12 months and see what comes back.
Does your contract have a maintenance window clause? Pull the SLA section and look for language around “scheduled maintenance” or “maintenance windows.” If it's there, ask when the last five maintenance windows were and what happened to tracking during each one.
Has tracking ever been down when you needed it most? This is an operational question, not a technical one. If your dispatchers or operations managers have a story about “that time the tracking went down,” that story is your reliability benchmark. How often does it happen? How long does it last?
What happens to your data during an outage? Are gaps in the log permanent? Does the device buffer and replay? Does a missed alert get sent retroactively or silently dropped? The answer to this question determines whether a short outage leaves a lasting compliance and safety impact or whether it just causes a brief inconvenience.
The compounding cost of low reliability
Fleet software pricing is usually evaluated on a per-vehicle-per-month basis. A platform at $15/vehicle/month looks better than one at $20 until you account for the cost of the reliability delta. One theft during a maintenance window — one truck, one load, one insurance excess, one investigation — is likely to cost more than the annual price difference across the entire fleet.
This is the calculation that rarely gets made because the cost of downtime is invisible until something goes wrong. The logic is the same as not having a spare tyre because you've never had a puncture. The day you need it, the inconvenience doesn't feel like a savings.
Reliability is not a premium feature. It is the baseline that everything else depends on. A driver safety score that doesn't update during an outage is not a safety system. A geofence alert that doesn't fire during a maintenance window is not a theft deterrent. A compliance log with gaps is not a compliance log.
ViaLoop Fleet's uptime history is public at status.vialoop.in. Every incident is logged with a timestamp, impact scope, and resolution note. That's what a reliability commitment looks like in practice — not a claim in a sales deck, but a verifiable historical record that a fleet manager can read before signing a contract.