Rerouting before the rain

In late September 2024, Hurricane Helene washed out I-40 at the North Carolina-Tennessee border. Within days, the state DOT issued an unusual warning to truckers: stop using Google Maps, Waze, and Apple Maps. The consumer navigation apps kept sending large trucks down narrow mountain detours built for cars, not 40-ton rigs. Trucks got stuck, flipped, or slid off the road trying to follow them.

The problem wasn't bad data — the closures and approved truck detours were posted on the DOT's own site. The problem was that the apps' routing logic doesn't reason about truck size or restrictions that are still evolving. It optimizes for the fastest path for a car and leaves the driver to discover the mismatch the hard way.

Fleet operations teams face the same gap. GPS pings stream in continuously, weather advisories update as conditions change, but the dashboards that connect them still refresh on a schedule — hourly, sometimes less. You get a heatmap of where trucks were. During a hurricane, you need to know where they will be, and whether that's a problem.

Hurricanes make the stakes obvious, but the underlying problem shows up anywhere conditions change faster than your analytics refresh: port congestion, traffic incidents, shifting customer demand. Deephaven handles this by joining multiple live feeds, updating incrementally as data arrives, and letting you query real-time and historical data with the same code.

The hourly refresh problem

Most fleet management systems treat real-time data the way a newspaper treats breaking news — they collect it all day and publish once. GPS pings arrive every 30 seconds, weather advisories update as conditions change, and traffic incidents appear and clear throughout the day. But the dashboard that's supposed to synthesize all of this refreshes on a schedule, and schedules don't care about hurricanes.

This isn't a knock on the tools - real-time data isn't what they were built for. A major fleet telematics vendor documents GPS data refreshing every three hours in their analytics warehouse, with driver aggregates updating once a day. Power BI Pro allows eight scheduled refreshes daily; even Premium caps at 48. These systems were designed for "how did last month look?" not "the road just washed out."

Custom alerting systems can catch specific patterns — "alert if truck enters polygon" — but hurricanes don't respect static polygons. The track shifts, flooding happens where the NHC didn't predict, and the fuel station you were counting on loses power. Every new scenario requires a new rule, a new deployment, and another wait.

What fleet operations actually needs is both: real-time detection that runs as fast as the data arrives, and the flexibility to ask new questions without filing a development request.

Joining weather, trucks, and trouble

This is what real-time fleet awareness looks like:

(Screenshots below are a single frozen moment of a table that's continuously updating — run the code yourself and you'll see different trucks, positions, and timestamps.)

Weather advisories stream in as polygons. GPS pings stream in as truck positions. Road closures and traffic incidents stream in as they're reported. One ticking table joins them all.

Now the join that matters — which trucks are heading toward trouble. Both sides are already reduced to one row per key (last_by("TruckID"), last_by("ZoneID")), so the cross join stays bounded — around 200 trucks × 10 zones, not an ever-growing pair count. A fleet large enough to need a bucketed or spatial join first would still update the same way; only the candidate-narrowing step changes:

Every time the weather service updates a zone (shifts the center, expands the radius, or raises the severity), every truck's risk status recalculates. Not at the next hourly refresh. Immediately.

From detection to decision

Knowing which trucks are at risk is step one. The dispatcher needs options. For each at-risk truck, what are the alternatives?

This isn't a black box. The dispatcher can filter, sort, and override. "Show me all trucks heading to Charleston, sorted by detour time." "Which WARNING-zone trucks have less than 2 hours of drive time remaining?" The queries run against ticking data — the answers update as conditions change.

Here's what that looks like in practice — a dispatcher dashboard fed by these ticking tables:

The same code, the day after

Storm passes. The question shifts from "who's at risk right now?" to "which shipments carried the most risk?"

DelayIfContinue was always a projected cost, not a measured one — how bad continuing would have been, based on the zone's severity at that moment. The debrief query doesn't change that; it just re-runs the same where clause to pull the high-projected-risk rows for review. Nothing about the code changes if you point it at a static historical table instead of a ticking one:

The analyst running the post-storm debrief uses the same syntax the dispatcher used during the storm. Point the query at yesterday's data instead of the live feed, and everything else works the same way.

The cost of an hour

Hurricane season runs June through November. A typical logistics company might face three or four significant rerouting events per year. Each one is a test: does your system move as fast as the storm?

An hourly refresh means the dispatcher is always behind. The driver calls in asking about conditions the system hasn't noticed yet. The reroute decision happens after trucks are already committed to bad routes. The fuel stop that lost power three hours ago is still showing as available.

Real-time awareness doesn't prevent hurricanes. But it closes the gap between what the driver knows and what dispatch knows — and that gap is where delays, safety incidents, and customer complaints live.

Try it yourself

Run the fleet monitoring example in your browser with Deephaven's live demo. To deploy in your own environment, follow the quickstart guide. Swap the simulated GPS feed for your telematics provider's API, and the weather simulation for NWS alerts — the downstream logic works identically.

Questions about logistics use cases? Join the conversation on Slack.