A dashboard that trails the messages by two steps
The complaint is always the same shape: an email says the parcel left the warehouse, the dashboard still shows it on the shelf, and the tracking page shows nothing at all. Three views of one parcel, three different answers.
Our own record contains the same pattern. Two of 24 parcels showed no tracking event for three days after release and then appeared three stages further on, while the warehouse row had already moved (Recorded, window 2026-08-01 to 2026-09-30).
The lag is usually a display problem rather than a lost parcel. Sorting that out takes three checks in a fixed order, and the cheapest check comes first.
Put a number on the lag before deciding what it means. Two hours behind is a refresh cycle, twelve hours behind is a batch that has not run yet, and two days behind is a parcel or an order that needs a question asked about it.
Where the lag comes from: a status field that refreshes on a schedule
A status field that refreshes on a schedule will always trail the underlying events. If the field updates twice a day, a parcel that moves at 09:10 and again at 14:40 can show the same label all afternoon.
Self-check: look at the timestamp beside the status rather than the status itself. A field stamped this morning is current even when its label looks stale, and a field stamped two days ago is the one to distrust.
1. Find the timestamp on the dashboard row. 2. Compare it with the current time. 3. If it is more than 12 hours old, note the time and refresh once. 4. Do not refresh more than once; the label will not change faster than its batch.
Find the timestamp before you read the label. Most lag stories end at that point, because a field stamped this morning was correct this morning, and the label it carries describes a state that may not have changed yet rather than one that has changed and been missed.
A status history is more useful than a status label. Where the panel keeps a list of past states with times beside them, the newest row is the answer, and a label that looks stale next to a timestamp from ten minutes ago is simply a state that has not needed to change yet.
A tracking number issued before the carrier has scanned anything
A tracking number can be created at the moment a parcel is packed, and the line may not scan it until the parcel reaches a sorting hub. That gap produces a number that returns no result for a day or two, which reads like a broken lookup.
Self-check: compare the date the number was issued with the date the parcel was marked outbound. Where the number is younger than the outbound mark by more than 48 hours, the missing scan is inside normal handling rather than a fault.
A number that returns no result on day four is a different case. Two of our own rows sat quiet for three days and then showed three stages at once, so patience is right up to about day three and a question is right after it (Recorded, 24 parcels).
A tracking number that returns nothing for four days is past the point of patience. Our own rows sat quiet for three days and then showed three stages together, so three days is normal and four is the day to send a question (Recorded, 24 parcels, window 2026-08-01 to 2026-09-30).
A browser session holding a page it loaded hours ago
Sessions are the third candidate: a page held in a browser can keep showing the version it loaded an hour ago, particularly on a phone left on the order screen overnight. The stored view and the live view then disagree while neither is wrong.
Self-check: open the same order in a private window or on a second device. Where the two views differ, the session is the cause and the live view is the answer.
1. Open a private browsing window. 2. Sign in again. 3. Load the same order. 4. Compare the two status labels and keep the newer timestamp.
The private window test costs twenty seconds and settles the most common cause. Signing in again also refreshes any cached view attached to the old session, which is why the two steps belong together rather than as alternatives.
Ruling the three explanations out in the cheapest order
Run the three checks in cost order: session first, because it takes 20 seconds; batch timestamp second, because it takes a minute; tracking-number age third, because it needs a date comparison.
Stopping at the first explanation that fits saves the effort of the other two. Where a private window shows a fresher state, the batch and the number were never the problem.
1. Private window check. 2. Status timestamp check. 3. Tracking number age check. 4. Write down which one explained the gap so the next lag is faster to read.
Write down which check explained the gap. Three lag episodes in a month usually share one cause, and a note that reads session, session, batch is enough to tell you where to look first next time.
Add the order screen to the three checks as a tie-breaker. The dashboard, the tracking page and the order screen each update on their own schedule, and the order screen is usually the closest of the three to what the warehouse has actually done, which makes it the one to believe when two of them disagree.
When none of them fits: what to send, and when a reply arrives
If a private window shows the same stale state, the timestamp is fresh and the tracking number is older than 48 hours with no scan, the parcel itself needs a look rather than the page.
Send three things: the order number, the last status with its timestamp, and the tracking number with its issue date. Three lines of evidence route faster than a paragraph of description, because nothing in them needs interpreting.
Expect a shelf check rather than an instant answer. A warehouse enquiry takes a working day in our experience, and the reply usually arrives as a status change rather than as a message (Recorded, 24 parcels, window 2026-08-01 to 2026-09-30).
Keep the enquiry dated. If a parcel turns out to be genuinely stuck, the date you first asked is the figure that decides whether the storage clock or the line is responsible.
Expect a shelf check rather than a message back. A warehouse enquiry in our own experience produces a status change within a working day, and the reply often arrives as a movement on the order screen rather than as an answer to anything you wrote.
Follow up on a cadence rather than on a feeling. Day one for the first enquiry, day three if the status has not moved, and day five only if the parcel is inside a claim window. A status change often arrives before the reply does, so the order screen is worth reading each morning even when nothing has been written back to you.
The data point behind this note
Two of 24 recorded parcels showed no tracking event for three days after release and then jumped three stages at once, while the warehouse row had already moved (Recorded, 24 parcels).
Rates last checked 2026-10-02. Where a figure is community-reported we say so; where we could not verify it, we write Not verified instead of estimating.