Coverage Scanner
Developer Guide
Find configuration problems before your customers do.
A misconfigured shipping zone is invisible — right up until the moment a customer can't complete their purchase. By then, the damage is already done: a lost sale, a frustrated customer, and potentially a negative review or a support ticket to deal with.
The Coverage Scanner is a built-in diagnostic tool that analyses every shipping zone across your store and surfaces configuration problems proactively — before a single customer is affected. Run it after any configuration change, before a peak trading period, or as a routine health check to stay confident that your checkout is working exactly as intended.
It doesn't just flag missing rate tables. It understands the full complexity of your configuration — rate brackets, scheduled windows, order value gates, tag-based routing — and checks that they all work together without gaps or silent failures. Navigate to Coverage Scanner in the admin sidebar, select a store, and click Scan coverage to run the analysis instantly.
What the scanner checks
The scanner evaluates every zone against ten categories of issue, each raised as an error, a warning, or an informational note. Most of these would be undetectable without running a live rate request to a specific address — the scanner surfaces them all in one pass.
- No active rate tables — the zone has no rate tables at all, or every table is disabled. Any customer with a destination in this zone will reach checkout and see no shipping options.
- Bracket gaps — for
weight,price,per_itemanddimensionaltables, the scanner walks the active rules in order and reports any value that no bracket covers: a hole below the first bracket, a gap between two brackets, or a missing catch-all above the last one. This is the check that most often finds real, silent revenue loss — a basket landing in an uncovered bracket simply returns no rate. - Order value gaps — when multiple rate tables use
minOrderValue/maxOrderValueguards, the scanner merges the ranges every active table covers and reports any hole in the combined coverage, plus any ceiling above which nothing is covered. - Expiry with no replacement — an active table with a
validTothat no future-scheduled table on the same zone and carrier picks up from. Raised as an error inside 7 days of expiry and a warning inside 30 days. The most common issue when setting up seasonal pricing. - Carrier expiring before its table — a carrier whose
validTofalls before thevalidToof a rate table that depends on it, so the table goes dark while it still looks scheduled. - Tag coverage gap — no active table in the zone is unrestricted, where unrestricted means a table with neither
requiredTagsnorexcludedTagsset. Without such a fallback, a basket that matches none of the tag rules returns no rates at all. Raised as an error. - Tag conflict — the same tag appears in both
requiredTagsandexcludedTagson one table, which can never match any basket. See Tags & Routing for why exclusion always wins. - Orphaned or dead tables — a table whose carrier no longer exists, or a table whose rules are all inactive. Either way it can never return a rate.
- Mixed currencies — active rules on one table quote in more than one currency. Only one currency per table is recommended.
- Free shipping and delivery notes — informational only: a
freetable with nominOrderValue(everything ships free); two different tables giving a free rate on the same carrier over an overlapping order value range (buyers see two identical options); aflatorfreetable with more than one active rule (only the first is ever used); and a carrier with no delivery days set (it always sorts last infastestmode).
Zone statuses at a glance
After the scan, every zone is assigned one of four statuses. The summary bar at the top shows the count in each category so you can see your overall coverage health immediately.
| Status | Meaning | Action required |
|---|---|---|
| Fully covered | At least one active rate table with no detected issues. The zone row is badged with its active table count. | None — this zone is healthy. |
| Has gaps | Active tables exist but one or more errors or warnings were detected. The zone row is badged gaps exist. Rates will still be returned but may be incomplete under certain conditions. | Review and resolve the issues in the expanded zone row. |
| No coverage | No active rate tables at the scanned date and time. Orders to this zone will receive no shipping options at checkout. | Create a rate table for this zone or enable an existing inactive one. |
| Zone inactive | The zone itself is disabled and excluded from all rate evaluation. No further checks run against it. | Enable if it should be active, or leave as-is if intentionally disabled. |
Drill down into any zone
Expanding any zone row reveals the full picture of what the rating engine will do for orders to that destination.
- Active tables — currently eligible rate tables that will be evaluated, including rate type and carrier.
- Skipped tables — tables that exist for this zone but are not active at the scanned date and time, each listed with its reason: the table is disabled, scheduled to start later, or expired; its carrier is missing, disabled, scheduled to start later, or expired; or the carrier and table windows never overlap at all. Order value is not a skip reason here — the scanner has no basket to price, so value guards are assessed by the order value gap check instead.
- Warnings and errors — specific, actionable messages for each issue detected with enough context to identify the root cause.
Scan any moment, or any basket
Two optional controls sit next to the Scan coverage button. Both change what the scan is evaluated against, so you can answer questions about the future rather than only the present.
- Check date & time — scan against any past or future moment instead of now. Every schedule check, and the whole active/skipped split, is evaluated at that datetime. This is how you confirm that Black Friday has coverage before Black Friday arrives: set the date, scan, and see exactly which tables would be live. Leave it blank to use the current date and time.
- Simulated basket tags — supply a tag set and the scanner reports which active tables that basket would fail to match, and which required tags it is missing. Useful for confirming a
cold-storageorhazmatbasket still has somewhere to land in every zone. Leave it empty to skip the simulation. See Tags & Routing.
Common fixes
| Issue | Fix |
|---|---|
| No active tables | Create a rate table for this zone, or enable an existing inactive one |
| Bracket gap / no catch-all rule | Extend the surrounding brackets to meet, or add a final rule with no maxValue so every value above the last bracket is still covered. See Rate Types |
| No unrestricted table | Add a rate table with neither requiredTags nor excludedTags set — a table carrying only excluded tags does not count as a fallback |
| Tag(s) in both required and excluded | Remove the tag from one of the two lists — exclusion is evaluated first, so the table can never match while it appears in both |
| Expires — no replacement scheduled | Schedule a successor table on the same zone and carrier whose validFrom starts no later than a day after the outgoing table's validTo. The check only looks 30 days ahead, so it fires as expiry approaches. See Scheduling |
| Carrier expires before rate table | Extend the carrier's validTo to at least the table's, or shorten the table to match the carrier |
| Order value gap | Make the ranges meet. Ranges within 1 minor unit are treated as continuous, so a maxOrderValue of £49.99 followed by a minOrderValue of £50.00 is accepted — no need to overlap them |
| Mixed currencies in rules | Split the table so each one quotes in a single currency |
| Ungated free shipping | Set a minOrderValue on the free rate table, or confirm always-free shipping is intentional |
| Duplicate free shipping | Remove or gate one of the two tables so buyers do not see two identical free options on the same carrier |
Built to work alongside every other feature
- Scheduling — the essential companion to scheduled rate tables. Set up your seasonal pricing, then run the scanner to confirm every expiring table has a successor lined up behind it — and use the check date to scan the season itself before it starts.
- Tags & Routing — checks whether your tag configuration leaves any order type without a valid rate, and flags zones where untagged orders would fall through.
- Rate Types — walks the brackets of every weight, price, per-item and dimensional table for holes and missing catch-alls, and merges order value guards across tables to prove every possible order value is covered.