Shopify Tracking Stuck After Fulfillment: What I Keep Finding

You already refreshed the order. You clicked the tracking link and saw the package moving on the carrier's own site. You compared that to what Shopify shows and the two don't agree. You have probably already asked support, who told you to wait 24 hours, and it has been three days. Customers are emailing. The order still says "Tracking added" like nothing has happened since Tuesday.

I get this problem in audits more than any other shipping issue. It is not one bug. It is a family of them, and the reason Shopify tracking stuck at "Tracking added" survives every attempt to fix it is that the different flavors of it look identical from the merchant admin. Same field, same status pill, same silence. What I do first, and what I do second, depends on which flavor I am actually looking at. Here is roughly the order I work through it.

The distinction Shopify does not surface in the admin

Shopify has two modes for tracking a shipment and it never tells you which mode you are in.

Native mode is when you buy the label through Shopify Shipping - USPS, UPS, FedEx, DHL eCommerce on the US side, Royal Mail, Canada Post, Australia Post, a short list. Shopify owns the carrier API credentials, polls the carrier at whatever interval it uses, and updates the order status when the carrier says the package moved. The post-purchase emails ("Out for delivery", "Delivered") fire because Shopify has authoritative status data.

Manual mode is when you type or paste a tracking number into the fulfillment form, or a shipping app (ShipStation, Easy DHL, Parcel Panel) writes a number in via the fulfillment API. Shopify stores the string. It builds a clickable link. That is it. There is no polling. The status stays at "Tracking added" until a human changes it. Native and manual look identical at the point of fulfillment, which is the whole trap.

The community thread on this has been open since 2023 with no resolution. SoCalMacGuy put it plainly on Shopify Community 252407 a couple of years back: it does not matter whether it is UPS, FedEx, USPS, or DHL - many orders will remain at "Tracking added" forever. He is right, and the reason, more often than not, is that the merchant is in manual mode without knowing it.

What I check before I touch anything

When someone brings me one of these, three questions decide almost the whole diagnosis:

Where did the label come from? Shopify Shipping, or somewhere else (a carrier portal, ShipStation, an ERP like JTL, a supplier email)?
Which carrier? Is it on Shopify's native poll list (roughly 30 to 40 carriers globally, out of hundreds in use)?
Is the tracking link Shopify built actually correct? Click it. If it opens the carrier homepage instead of the package page, Shopify's pattern-matcher misidentified the carrier and you have a second problem stacked on top of the first.

If the answer to (1) is anything other than Shopify Shipping, or (2) is anything other than a carrier on the polled list, the status will never move on its own. Nothing you do in the admin will change that. You are in manual mode. The fix is either buying labels through Shopify Shipping (rarely realistic, since most of these merchants have carrier accounts with better rates), or installing a third-party tracking app (17TRACK, AfterShip, Parcel Panel) to do the polling Shopify does not.

I keep the app recommendation quiet at this stage because half the audits I do also involve a tracking app that is already installed and quietly making things worse. That is the second half of the article.

The failure modes that are not the merchant's fault

Even when the merchant is in native mode with a supported carrier, Shopify tracking stuck still happens. The community threads are stacked with cases that have no self-service resolution.

Royal Mail, June 2026. The native sync stopped for about a week. Every UK Royal Mail order in every Shopify store went to "Tracking added" and stayed there while the parcels themselves kept moving. There was no in-admin notification. Oscar_Harper's line on Shopify Community 632263 is the honest summary of the merchant experience: the annoying bit is you have no way of knowing which parcels are genuinely stuck versus just not scanning yet. When I hit a case like this in an audit, the tell is that it is only one carrier, and only for the window of the outage. Fixed by waiting.

DHL Express looks native and is not. DHL Express is listed in Shopify's GraphQL tracking company documentation. It builds clickable tracking URLs. On paper it looks like a native integration. In practice, Shopify does not receive delivery status pushes from DHL Express - orders stay at "Fulfilled" while DHL's own site shows delivery. A Shopify developer confirmed the gap on Community thread 583312 in January: being in the tracking company list does not mean an active status-polling integration exists. DPD on that same merchant's store worked; DHL Express did not. If I see a store where every carrier updates except DHL Express, this is the first place I look.

GLS misidentified as DHL through the ERP. German merchants using JTL to push tracking numbers into Shopify hit this. JTL sends the tracking number and a carrier name string but not the full tracking URL. Shopify then pattern-matches the number format against the carriers it knows. GLS's format looks enough like DHL's that Shopify generates a DHL tracking URL and labels the shipment "DHL" in customer emails. The correct number goes out. The link is wrong. Customers click through to DHL's site, which does not recognize the number, and email the merchant. The community expert Gabe put the platform behavior clearly on thread 267020: Shopify attempts to generate a valid tracking URL by pattern matching but does not validate the tracking URL itself. The fix is on the ERP side - pass the full carrier-specific URL - but most ERP users do not know the distinction exists.

La Poste and the six-month detection lag. In 2023, La Poste rolled out a new 14-character tracking format starting with "8850000". Shopify's auto-detector classified the new numbers as Australia Post or DHL Express. Wrong links, wrong carrier name, wrong everything. The workaround in the interim was to manually select La Poste from the carrier dropdown for every fulfillment, roughly 20 times, before auto-detect caught on. The actual algorithm fix took from May to November - six months - and required escalating to Shopify's developer team. I have not seen a case this severe since, but the pattern (carrier changes format, Shopify's algorithm lags by months) recurs.

USPS stuck as a permanent state. Even with native polling, USPS orders confirmed delivered by the customer can stay "in transit" or "out for delivery" in Shopify forever. This is a UPS-and-USPS carrier-side problem, not a Shopify problem, and Shopify has no admin control that overrides carrier data. Two Shopify support agents on Community thread 278666 gave opposite answers about whether an internal team could push the status. Neither answer was marked as resolution. I tell merchants to mark the order complete in the order admin (which changes the order status, not the tracking display) and treat the tracking discrepancy as cosmetic.

The three-surface mismatch. In August 2026, Shopify's merchant dashboard flagged every USPS package as "Package arriving late" for about a week while the carrier's own site and the customer-facing order status page both showed on-time delivery. The dashboard was wrong. If you check only the merchant admin and act on what it says, you make operational decisions on stale data. I now tell every merchant I audit to trust the customer-facing tracking page over the admin dashboard when the two disagree, because that is what the customer will act on.

The tracking-app trap most merchants do not see coming

Half the Shopify tracking stuck cases I take are actually "the tracking app I installed to fix it is now the problem." The apps are real fixes for the native gap, and I recommend them regularly, but they carry their own failure modes and merchants under-price the risk.

Track123 template rewrites persist after uninstall. When Track123 installs, it edits your Shopify notification email templates and replaces the native {{ fulfillment.tracking_url }} liquid variable with its own redirect URL. When you uninstall the app, those template edits do not roll back. Hraz's thread on Community 564153 is the canonical case: months after uninstalling Track123, customer emails were still routing tracking links through the app's now-defunct pages. The fix is to open Settings > Notifications, find each shipping email, and restore the native liquid variable by hand. I have never once seen a merchant notice this on their own. It surfaces when a customer emails asking why the tracking link is broken.

AfterShip billing surprises. AfterShip has the deepest Shopify integration and the prettiest branded tracking pages of any option, and it is the app I recommend most often for stores past a few hundred shipments a month. It is also the one most likely to produce a surprise invoice. One merchant reported $700 in per-shipment overage fees accumulated silently on the free plan. A separate case reported a $26,000 bill after a malicious attack pushed fraudulent tracking numbers through the account. In both cases AfterShip declined refunds. If you use AfterShip, set a calendar reminder for the 45-day mark to audit shipment volume - that window is where accumulated overage tends to become visible.

AfterShip's Royal Mail plan gate. In mid-2026 AfterShip restructured its carrier plans and moved Royal Mail to Premium and Enterprise tiers. UK merchants on the Standard plan lost the integration without much warning. If your Shopify tracking stuck problem is on Royal Mail specifically, and you already have AfterShip, confirm the carrier is available on your current plan before you spend an hour re-diagnosing.

17TRACK is cheaper and slower. 17TRACK's free tier covers 50 shipments a month, which is where a low-volume merchant should start. The polling interval on the free and low tiers, though, is long enough that "delivered" emails routinely arrive two to three hours after the carrier scan. If your customer service pattern is "we know before the customer does," 17TRACK on a free tier will not give you that. On paid tiers the interval shortens, but the delay is a real cost people do not model in advance.

Parcel Panel can show its own "Info Received" stuck status. Ann-Chan of BestTrack diagnosed this cleanly on Community thread 608420: the carrier's own site shows the package in transit while Parcel Panel keeps showing "Info Received" because the app is polling the wrong carrier for that shipment. If you moved off native tracking to solve Shopify tracking stuck and now have Parcel Panel tracking stuck, the fix is usually a carrier-mapping correction inside the app's settings, not a re-install.

I recommend BestTrack now for the very small merchant with 300 or fewer orders a month who mostly needs the pre-first-scan gap covered (custom "packed" and "handed to carrier" checkpoints), because their free tier is more generous than 17TRACK's for that use case. It does less than AfterShip; it also costs less to be wrong about.

What I actually do when someone needs Shopify tracking stuck fixed today

Practically, in a session where a merchant messages me at 4pm because customers are asking about packages that shipped Monday:

I confirm which carrier, whether the label came from Shopify Shipping, and whether any tracking app is installed. That takes three or four minutes.
If manual mode with no app: install 17TRACK on the free tier if volume is under 50 a month, or AfterShip Standard with overage alerts turned on. Configure the delivered webhook to fire a Shopify Flow that marks the order and sends the missing post-purchase email.
If an app is installed and misbehaving: check for the Track123 template residue first, then the AfterShip plan gate, then the Parcel Panel carrier mapping. In that order because that is roughly the frequency I see them.
If native mode is broken on a native carrier: check the Shopify status page and the Payments/Shipping Community forum for others reporting the same window. If it is an outage, wait. If it has persisted more than three or four days, layer a tracking app as a temporary parallel tracker and revert when the native sync comes back.

That decision tree is a lot to run through cold at 4pm on a Friday with a queue of customer emails. If you want a second set of eyes on your specific case before Black Friday shipping volume hits, the first 15 minutes with a help1 expert is free and that is usually enough to get through the diagnosis and pick the right app. The related pattern of Shopify quietly disconnecting a carrier account itself - a different problem that produces similar-looking symptoms in a different place - is in what I keep finding when Shopify carrier integration breaks.

What I would tell you not to do

Do not delete and re-add the tracking number. It does not re-trigger polling because there was no polling to re-trigger. Do not switch tracking apps in the middle of a live shipment; the new app will not backfill the in-flight parcels and you will have two systems of record for a week. Do not accept "wait 24 hours" from support as an answer past the first day - if the carrier's own site shows movement and Shopify does not, waiting is not the fix.

The thing I underestimated for about two years is how much of this is architecturally invisible from the admin. There is no "Native polling: on" toggle. There is no warning when a carrier drops off Shopify's supported list. There is no error when the pattern-matcher builds a wrong tracking URL. Shopify tracking stuck stays stuck partly because the interface never tells you which of the ten different reasons is yours.

The gap between a package that has moved and a status that has not is where most of a store's trust quietly leaks out.