What the app watches, how it decides a parcel needs attention, and what it deliberately leaves to you.
Every time your store creates a fulfillment with a tracking number, Delivery Radar picks it up. There is nothing to configure and no list to maintain.
For each shipment it collects the carrier's scan history — the timestamped events a parcel generates as it moves — and keeps checking for new ones. Carriers publish updates every few hours at most, so the app checks on a matching rhythm rather than hammering them pointlessly.
The dashboard shows Last synced, and that timestamp only moves when a check actually succeeds. If it starts falling behind, something upstream is failing and you'll be able to tell — rather than looking at stale data that claims to be fresh.
Two different things can flag a parcel: what the carrier explicitly reports, and how long the parcel has been silent.
Some events need no interpretation. When a carrier reports a failed delivery attempt, a refusal, a customs hold, a return to sender, a confirmed loss or damage, the app surfaces it immediately. No waiting, no thresholds — these bypass every timer.
Most problems don't announce themselves. A parcel simply stops moving, and nobody says anything. This is where the app does its real work.
Delivery Radar measures how long a parcel has gone without a physical scan — an actual handling event, not an electronic "information received" notice that a label was created. Those two look similar in a tracking feed and mean very different things.
That silence is measured in working hours, not calendar hours. Sundays don't count. Public holidays are handled for the UK, Ireland and Romania, and UK bank holidays count as partial days rather than being ignored or counted in full.
The threshold that silence is compared against depends on the route:
A label created but never picked up is its own failure mode, and a common one. The app treats it separately: below a normal first-scan window the parcel is left alone, because carriers often take a day to register a collection. Past that window it escalates, and past a longer one it escalates again.
Until then, the app says plainly that the label was created recently and no scan has appeared yet — rather than implying the carrier has lost something.
A compact view of the same thing. Time-based rules are measured in working hours since the last physical scan, and the exact figures are tuned as we see how carriers actually behave — treat these as the current shape, not a fixed contract.
| Level | Triggered by |
|---|---|
| Watch | A first failed delivery attempt · a domestic parcel silent for a couple of working days · a label with no carrier scan after the normal first-scan window |
| Action needed | A second failed attempt · held at customs with action required · refused by the recipient · an address problem flagged by the carrier · a return to sender in progress · out for delivery with no further scan · silence well past what the route should take |
| Critical | Confirmed lost · confirmed damaged · a completed return to sender |
| Not tracked | An unsupported number type · skipped because a monthly limit was reached · too old for the carrier to still hold history |
International parcels get longer thresholds than domestic ones, scaled by transport mode, and customs is judged separately by country pair. Critical triggers ignore timing entirely — they fire the moment the carrier reports them.
Delivery Radar requests exactly two Shopify permissions:
read_orders read_fulfillments
Both are read-only. The app cannot modify your orders, products, customers, themes or settings — it has no write access of any kind. It also does not request access to your customer database; recipient details come from the shipping address on the order itself.
You can verify this on the install screen before granting anything.
Carriers differ in how promptly they scan. Some are consistent; others go quiet for a day and then post four events at once. If the app is more nervous than your carriers deserve, the alert delay buffer in Settings adds extra patience across every time-based rule.
Critical alerts are never delayed by the buffer. A confirmed loss doesn't become less urgent because you asked for more patience elsewhere.
These are decisions, not gaps. Each one exists because the alternative causes more harm than it prevents.
It never contacts your customers. The message is prepared and handed to you. Carrier data is sometimes wrong or delayed; an app that messaged customers automatically would eventually apologise for a parcel that was never late. Keeping you in the loop means a bad data point costs you a glance, not your reputation.
It doesn't predict delivery dates. Estimates that turn out wrong do more damage than no estimate at all.
It doesn't build a customer-facing tracking page. That's a different product, and there are good ones already.
It doesn't invent data. If a carrier publishes nothing, the app says so. It never fills a gap with a plausible guess.
It isn't a record for claims. The data comes from carriers through a third-party provider, and it is frequently incomplete or delayed. For a claim, a dispute, or anything with financial consequences, use the carrier's own records. The app's job is to tell you which parcels deserve that attention.
Delivery Radar reads what carriers publish. When a carrier is slow to publish, or publishes something wrong, the app shows the same thing — there is no way to turn bad source data into good data.
What the app can do is interpret carefully, be explicit about what it knows, show you when it last managed to check, and never turn uncertain information into an automatic action. That's the difference between reporting a status and being trusted with one.
Questions this page didn't answer are probably in the Guides FAQ.
We'd like to measure how people find this site. We use Google's advertising cookies to see which searches and ads bring merchants here. Nothing runs until you choose, and declining changes nothing about how the site works. Read the privacy policy.