TopN AnalyticsEliminating False Alarms in a Fleet Analytics Data Platform's Daily Refresh
A leading pan-India fleet management company that supplies vehicles to driver-partners operating on ride-hailing platforms.
Where things stood
The company's daily operations scorecards — covering vehicle allocation performance, driver headcount, and fleet utilization — were refreshed by a shared, general-purpose query-automation engine that wasn't designed for time-sensitive, business-critical dashboards.
A single hung refresh run could silently block every later attempt that day; on one occasion a run hung for more than 20 hours, and operations leadership received no updated dashboard all morning. Separately, the query powering vehicle-utilization dashboards recomputed 19.4 million rows of two-and-a-half years of history every single day, a workload that increasingly exceeded the database's five-minute execution limit and had been failing intermittently for roughly three weeks.
A subtler problem compounded both: distinguishing 'the source data legitimately hasn't landed yet' from 'something is actually broken.' Early fix attempts got this wrong — for 13 consecutive days the on-call channel received a failure alert every morning even though the pipeline reliably caught up an hour later each time, undermining the value of the alert itself.
When these dashboards weren't reliably refreshing on time, operations teams fell back on manual alternatives, costing roughly three to four hours of delay each day.
What we built
MySQL source system feeds a PostgreSQL analytics warehouse, through a shared query registry (so business analysts keep authoring SQL in one place) into a dedicated Airflow pipeline with per-tab freshness gating, incremental refresh, and Slack-based alerting.
The heaviest query was converted from a full historical recompute to an incremental refresh limited to the trailing 30 days, cutting its runtime to a fraction of a minute — comfortably inside the existing five-minute limit, with no need to raise it.
A per-tab freshness gate checks whether each dashboard's upstream data has synced for the day before refreshing it, with built-in retries letting a late-arriving source self-heal within the same morning.
How it works
TopN Analytics rebuilt the refresh process as a dedicated, purpose-built pipeline rather than patching the shared engine.
Most distinctively, the pipeline now separates 'waiting on data' from 'an actual failure': a dashboard is only escalated to a real alert if it's still not ready at or after the team's published 10:30 AM commitment — before that, a late source is an expected deferral, not an error. This distinction is what ended the two-week run of false alarms.
What we delivered and learned
Both defects were dated and diagnosed precisely rather than fixed by guesswork: the single-hung-run outage occurred on a specific date, and the false-alarm pattern recurred for exactly 13 consecutive days before being root-caused and fixed.
The redesigned query stayed within its existing timeout rather than requiring a higher limit — a more durable fix than simply raising a ceiling.
What it's built on
Want the full picture?
We're happy to walk through the details, numbers, and trade-offs directly.