A Stale ETA Needs a New Answer, Not Another Alert

Key Takeaways

An ETA goes stale when the data behind it is older than the next event the load should have produced. Another alert about it changes nothing.
The fix is a new answer: a fresh ETA, the reason it moved, who confirmed it, when, and when the load will be checked again.
Wilson, by Cartage, checks the best source available for each load (carrier API, GPS or ELD data where available, the carrier website by PRO number) and emails or calls the carrier when those sources can't answer.
Staleness should be defined by load type: an FTL truck with GPS goes stale faster than an LTL shipment between terminal scans.
A carrier that doesn't reply is a result to record and escalate, not a reason to leave the old ETA on the screen.

When is an ETA stale, and what should replace it?

An ETA is stale when the data behind it is older than the next event the load should have produced. What replaces it is not a warning but a new answer: an updated ETA, the reason it changed, who confirmed it and when.

The ETA on a shipment screen is a calculation from the last data point anyone received. Take an FTL load picked up at 6 a.m. The last GPS ping came in at 9:40 a.m. It is now 2 p.m., and the screen still says delivery at 5 p.m. Nothing from the last four hours supports that number. The truck could be on schedule, parked for a repair, or stopped because the driver ran out of hours.

Age alone doesn't make an ETA stale. An LTL shipment may go hours between terminal scans, and that is normal. A missed arrival scan at the destination terminal is not. The useful test compares the age of the last trusted event with the cadence that source normally keeps for that kind of load.

A second alert only tells the coordinator what they already suspected. Someone still has to open the carrier portal, email the dispatcher, wait, call and write down the answer. The stale-ETA buyer's evaluation compares tracking systems on this point. The focus here is the work itself: getting from an old number to a confirmed one.

The stale-ETA response sequence: from old data to a confirmed answer

Seven steps take a load from "the data stopped" to "the carrier confirmed a new ETA, and it's on the record."

Flag the ETA as stale. Record the last trusted event, its timestamp and its source. Mark the ETA unconfirmed so nobody quotes it as current.
Check the next available source. If the carrier API is quiet, try GPS or ELD data where it exists, then the carrier website by PRO number. A fresher source that matches the plan can close the question. One that contradicts it moves the load to outreach.
Contact the carrier. Email the dispatcher, or call right away when delivery is close and calls are configured. Ask for the current location, the ETA, the reason for any change, and whether the delivery appointment still holds.
Capture the new answer. Write down the ETA as a window, the reason, who gave it and when.
Set the next check. The reason drives the timing. A truck waiting on a repair gets checked when the repair should be done. A load held at a terminal gets checked at its next departure.
Record the change. The old and new ETAs both stay on the shipment, and notification rules decide who hears about it.
Escalate when no answer comes. After the configured follow-ups, a person gets the case with everything already tried.

What does a complete new answer contain?

A complete answer has five parts: the ETA, the reason, the source, the timestamp and the next check.

A GPS ping tells you where the truck was. A PRO lookup shows the carrier's latest recorded status. Neither one explains the carrier's plan. A truck parked for two hours could be on a required break, waiting for a dock or broken down. Each means a different arrival time, and only the dispatcher or driver knows which.

The reason tells the team whether the new ETA is likely to slip again. Record reasons in consistent terms:

mechanical issue or repair in progress;
driver hours of service;
held at a terminal, or missed a linehaul departure;
delivery appointment moved;
weather or road closure;
no delay at all: a missed scan or a quiet feed.

The last item matters. Stale data doesn't always mean a late load. When the carrier confirms the truck is on schedule, that is also a new answer, and it keeps the team from sending a false delay notice.

The source and timestamp show how much weight the ETA can carry. "Dispatcher, by phone, 1:55 p.m." is stronger than "carrier website, updated this morning." The case for putting a timestamp on every tracking claim applies here too.

How should the team decide when to wait, call or escalate?

Outreach should depend on how close the delivery is and what the other sources say, not on who happens to notice the stale number.

A fresher source agrees with the plan. Update the record, set the next check and skip outreach.
No fresher source exists, or sources disagree. Contact the carrier. Don't blend two conflicting signals into an ETA nobody gave.
Delivery or an appointment is close. Inside a window the company sets, call first where calls are configured. A same-day delivery can't wait hours for an inbox reply.
The carrier doesn't answer. Try a second channel, then escalate with the last trusted event, every message sent and the decision now needed. Decide who escalates unanswered carrier messages before the first quiet load.
The new ETA breaks a commitment. A missed appointment or production need goes to a person who can decide on recovery.
Never fill the gap with a guess. Until someone confirms a time, the ETA stays unconfirmed.

Carriers that go stale over and over on the same lanes show up in shipment history, and a carrier-performance report can be pulled on request.

Stale-ETA rule sheet: an illustrative example

A rule sheet turns "the data looks old" into a defined trigger and next step for each kind of load. The thresholds are illustrative. Each company should set its own by mode, lane and how strict its customers' receiving windows are.

Load situation	ETA is stale when	Next source	Outreach step
FTL with ELD or GPS data	No position update for 2 hours in transit	Carrier API, then carrier website	Email dispatcher; call if delivery is within 4 hours
FTL with no tracking data	No check-in at the agreed interval	None	Call driver or dispatcher at the SOP interval
LTL with a PRO number	Expected terminal scan missing by end of day	Carrier website by PRO number	Email the terminal or carrier customer service
Any mode, appointment today	Last event older than the time left to the appointment	All available sources	Call first where configured

Worked example (illustrative). At 11 a.m. Wednesday, an LTL shipment shows "in transit" with delivery promised that day. The last scan was Tuesday at 6 p.m. at the origin terminal, and the PRO lookup shows nothing newer. An email to the terminal gets a reply at 12:30 p.m.: the shipment missed Tuesday's linehaul, leaves tonight and delivers Thursday morning. The record now holds the old ETA, the new ETA, the reason, the source and a next check for Thursday at 7 a.m.

How Wilson, by Cartage gets a new ETA when the data stops

Wilson tracks each load with the best source available and, when that source goes quiet or the load runs late, goes to the carrier for a new ETA and reason. Traditional logistics software gives teams information. Wilson executes the work required to move shipments forward.

Wilson uses the carrier API, GPS or ELD data where available, or the carrier website by PRO number. When those don't answer, it emails the carrier, or calls carriers and drivers where calls are configured, at the follow-up frequency set in the company's SOP. Messages, confirmations and changes are recorded in the shipment's change history, so the old ETA, the new one and the reason stay side by side.

Once the new ETA is confirmed, Wilson tells the team in Slack or Microsoft Teams and notifies other contacts as configured. When the carrier can't confirm, Wilson escalates with what it already tried. If the delay calls for a new carrier, Wilson initiates rebooking from the company's approved carriers, within the configured rules or after approval. Wilson starts with assisted execution, and the scope can grow step by step as the team gains confidence in the workflow.

If stale ETAs still turn into manual chases on your team, bring one load whose tracking went quiet last week and see whether Wilson comes back with a confirmed ETA and reason.