Six tablets that haven't seen new products in two weeks. Force-close, reinstall, log out, log in. The till is now a guessing game. Stock counts at end-of-day are wrong by exactly the items added recently. Staff have started writing prices on Post-its because they cannot trust the tablets. The Shopify status page says everything is green.
If that is your week, this article is for you. I am going to walk through how I diagnose Shopify POS sync failures, the five failure classes you typically hit, and how I would approach the fix on a real store. Then, if you want it applied to yours, the technical assessment is the route in.
This is not a "10 things to try" list. It is the actual method.
The Short Answer
Shopify POS sync failures across iPad and Android usually fall into one of five classes:
- Stale device session and cache. The most common.
- App version drift across devices. The most common silent cause.
- Location and permission misconfiguration in admin. Easy to miss.
- Webhook backlog or missed webhooks on the Shopify side. The cause when reinstalling fixes it for hours then it drifts again.
- A real Shopify-side incident. Genuine outage, rare, fixed when Shopify fixes it.
Reinstalling the app clears the local cache. Whatever caused the cache to stop accepting updates is still there. The lasting fix usually involves a clean inventory reconciliation pass, plus a documented recovery procedure, plus (where webhook backlog is the cause) a scheduled reconciliation layer that runs alongside real-time sync.
Why The Obvious Fix Fails
Before the diagnosis, the workarounds you have already tried, and why they keep coming back.
Force-close and reinstall. Clears the local cache. Whatever caused the cache to stop accepting updates is still there. You will see the drift return within hours.
Logging staff out and back in. Refreshes the session. Does not address the underlying webhook or location-permission issue. Same drift returns.
Waiting it out. Sometimes works (for genuine Shopify-side incidents, see class 5). For local-state issues, the drift increases the longer you wait.
Calling Shopify support. They can help with backend incidents and account-level issues. They cannot diagnose your specific multi-device drift pattern in your specific store with your specific app stack. The most common outcome is a long ticket and the same Post-it notes on the till.
Buying a different POS app. New app, same merchandise model, same backend, same sync constraints. Likely the same class of failure within months. You also retrain staff for nothing.
How I Diagnose This
The diagnosis is what separates a real fix from another reinstall. I work through the five classes in order, because that order matches both how often each class appears and how cheap each class is to rule out.
Class 1: Stale device session and cache
What it looks like. One tablet is fine, another is two weeks behind. Reinstalling the affected tablet works for hours and the drift returns. The store has been operating fine for months and the drift started without an obvious trigger.
How I rule it in or out. Compare the date the affected tablet last received a new product against the dates the unaffected tablets last received one. If they diverged on a specific day, this is a session/cache issue and not a webhook issue. The tablet's session token may have a stale view of locations or products and the next pull never reconciles.
The lasting fix. Document the exact sequence to recover (log out, clear app data, log in, force a manual sync from a specific screen) and put it on a one-page runbook your staff can run themselves the moment the drift starts. The fix is not avoiding the drift, it is closing the recovery loop from days to minutes. If recovery has to be run more than once a month, escalate to class 4.
Class 2: App version drift across devices
What it looks like. One tablet is in sync, another is not. They look identical. Both are on iPad. Both are logged into the same store. The behaviour cannot be explained by class 1.
How I rule it in or out. Check the app version on every tablet. Side by side. Yes, all of them. Shopify POS auto-updates do not always succeed silently, and a tablet that has been on Wi-Fi quirky for a week can stay on a build that is two minor versions behind. Different builds carry different sync logic. The build difference is the silent cause.
The lasting fix. Bring every tablet to the latest app version. Document the version they should be on. Add an end-of-week check ("are all POS tablets on version X?") to whoever owns the floor. If you cannot get a tablet to update, that tablet is the symptom and the fix is hardware-side.
Class 3: Location and permission misconfiguration
What it looks like. One physical store location is fine, another is not. Or, all tablets in the same shop are behind, but the online store is fine.
How I rule it in or out. Open Shopify admin. Go to Settings → Locations. Confirm the location each tablet is logged into actually exists, is active, has POS sales channel enabled, and the staff member tied to that tablet has permission for that location. Check the staff permission grid. Check the locations panel inside Shopify POS itself.
The lasting fix. Correct the location/permission configuration. This is rarely the cause once a store is past its first month, but I include it because it is the cheapest cause to rule out and the most expensive cause to leave undiagnosed (you will never reinstall your way out of a permission gap).
Class 4: Webhook backlog or missed webhooks
What it looks like. Reinstalling fixes it for hours and then the drift returns. App versions match. Locations are correct. Multiple devices are affected. The drift is asymmetric: products created today are not on the till tomorrow, but inventory adjustments at the till do reach the admin.
How I rule it in or out. Webhook subscription health. Open Shopify admin → Settings → Notifications → Webhooks (or use the GraphQL webhookSubscriptions query if you have an API token). For each relevant resource (products/create, products/update, inventory_levels/update, variants/update), confirm the subscription is active, recent deliveries are 200 OK, and the failure rate is not climbing. Webhooks fail silently. Shopify retries for a window and gives up. Once they give up, the only way to catch up is a reconciliation pass.
The lasting fix. This is where the reconciliation layer earns its keep. A scheduled job that runs every N minutes, queries Shopify for the resource state, and pushes the canonical state to whichever system is drifting. It does not replace real-time sync. It runs alongside, as a safety net. When real-time sync works, the reconciliation job is a no-op. When real-time sync drops a webhook, the reconciliation job catches up at the next interval. This is the engineering that turns the drift from a recurring fire into a footnote.
Class 5: A real Shopify-side incident
What it looks like. All tablets, all stores, all platforms (iPad, Android, web admin) drift simultaneously. The Shopify status page shows yellow or red. Other merchants on Twitter are reporting the same.
How I rule it in or out. Check status.shopify.com. Check status.shopifystatus.com. Check the Shopify Community thread. If it is a real incident, it is rare and there is nothing to fix on your end.
The lasting fix. None. Wait. Document that this happened, what the impact was, and how long the recovery took, so that you have a baseline if it happens again.
How I Would Approach The Fix On Your Store
Here is the engagement I would scope, end to end, on a real store with active drift.
Phase 1: Reconciliation pass (first call, day one)
The first call is to stop the bleeding. Drift compounds. Every hour the till has the wrong stock counts is another hour of oversells, refunds, and customer trust erosion. The reconciliation pass is the first deliverable.
What I do. Snapshot current admin inventory. Snapshot what each tablet thinks the inventory is. Diff them. Resolve the diff in favour of admin (because admin is the system of record, not the till). Push corrected state to every tablet. Confirm the next sale goes through with the right stock count.
Why this is non-destructive. I never modify on-hand counts without a reconciliation log. Every change is recorded with timestamp, original value, new value, and the reason. If we get something wrong, it is undoable.
Phase 2: Diagnosis (within the first week)
The reconciliation pass clears the immediate drift. It does not tell you why the drift happened. The diagnosis does.
What I do. Walk the five classes in order. Most stores test out as a mix of class 1 (stale cache, recoverable) and class 4 (webhook backlog, fixable). I write up which classes are present, which are dominant, and what the mitigation looks like for each. The diagnosis is a written document you can act on whether or not you proceed with me.
Phase 3: Fix path (week one to week two, scope-dependent)
Based on the diagnosis, the fix path is one of three shapes:
Configuration-only fix. Class 1, class 2, or class 3 as the dominant cause. The fix is a runbook for staff plus a configuration correction. Cost: small. Time: a few days, mostly documentation and training.
Reconciliation layer. Class 4 as the dominant cause. The fix is a scheduled job that queries Shopify for canonical state and reconciles drift. This is real engineering: webhook subscription audit, scheduled job hosted somewhere reliable, idempotent state push, observability so you can see when it runs and what it corrects. Cost: medium. Time: one to three weeks, depending on how clean your existing data is.
Hybrid. Most real stores. The runbook closes the recovery loop on the cheap classes. The reconciliation layer catches the silent failures. Together they turn POS sync from a recurring fire into a non-event.
Phase 4: Documented handover
You do not pay me to be irreplaceable. You pay me to make the system someone else can run.
What I deliver. The runbook your staff use when drift starts. The reconciliation layer's code, repository, deployment instructions, and observability dashboard. A monitoring alert that fires before staff notice. A handover call with whoever owns the systems internally so they can extend the work without me.
Honest Variables That Change The Cost Shape
Every store is different. The diagnosis tells me which of these apply to yours. I will not give a price before the diagnosis because the cost depends on which of these are true.
Number of locations. One location is straightforward. Five locations multiply the reconciliation surface. Each location has its own webhook subscriptions and its own staff permissions.
Number of variants. A 200-SKU store is different from a 20,000-SKU store. The reconciliation layer scales fine, but the initial reconciliation pass takes longer.
Existing integrations. If your inventory is already syncing to an ERP, an FBA reconciliation layer, or a wholesale platform, the reconciliation layer needs to play nicely with those. Sometimes that is the easier fix. Sometimes it surfaces a cleaner architectural change.
Plan. Standard Shopify, Shopify POS, Shopify POS Pro all work. Shopify Plus opens up a few extra options (Shopify Functions, custom apps with elevated scopes) that change the implementation but not the diagnosis.
Hardware. If the drift turns out to be a tablet that physically cannot keep its Wi-Fi connection alive, the fix is a tablet replacement, not a software engagement. The diagnosis will tell us.
Why I Wrote This
Most articles on "Shopify POS not syncing" tell you to force-close the app. You have already tried that. This article exists because the engineering reality is different and the buyer who recognises it is the buyer I want to work with.
If you read this and thought "yes, that is exactly the pattern I am seeing," the technical assessment is the route in. It is paid. It produces a written diagnosis, a fix path, and a scoped engagement quote. Most assessments take two to four hours of focused work, plus a written diagnosis returned within a week. You keep the diagnosis whether or not you book the fix.