---
title: Sync errors are piling up and you need to know which ones matter
summary: >
  Sync errors are a log of things an integration could not finish. Nearly all are
  one of two shapes: something arrived carrying a product code your catalogue does
  not have, or it arrived from a store location nobody has mapped. Both are
  grouped by target and counted, so one line can stand for thousands of failures.
  Fix the mapping once, then re-check to close every matching error together.
type: troubleshooting
group: sync
step: 7
permission: channels.manage
prerequisites: []
related:
  - /help/sync/ops-and-my-store-disagree
  - /help/sync/product-shows-zero-online
last_updated: 2026-08-07
---

**A sync error is not a crash. It is a note saying "this arrived, and I could not
find what it was talking about."**

Almost every one names something missing on your side: a product code the
catalogue has never seen, or a store location nobody has told this app about. That
is good news, because it means the fix is a piece of setup you can do once, not a
repair to each affected order.

- [What the page is showing you](#what-the-page-is-showing-you)
- [Check 1: is it an unmapped location?](#check-1-is-it-an-unmapped-location)
- [Check 2: is it an unknown product code?](#check-2-is-it-an-unknown-product-code)
- [Check 3: is it transient, or is it waiting for you?](#check-3-is-it-transient-or-is-it-waiting-for-you)
- [Closing errors in bulk](#closing-errors-in-bulk)
- [When an error will not clear](#when-an-error-will-not-clear)

Open **Sync errors** to follow along.
[Sync errors](/sync-errors)

## What the page is showing you

By default the page shows only unresolved errors, and it groups them rather than
listing them.

Three sections, in the order they deserve your attention:

1. **Unmapped locations.** Rare, and each one affects every order that came from
   that location. Highest impact, so it sits at the top.
2. **Unknown product codes.** More numerous, each affecting the orders that
   contain that one code.
3. **Other.** Everything that matches neither pattern — a payload that would not
   parse, a refund arriving for something already handled. These need reading one
   at a time.

Two properties of the log matter more than they sound:

- **Identical errors are folded together.** A repeat of the same failure bumps a
  count and a "last seen" time instead of adding a row. So one line reading
  "failed 4,812 times" is *one* problem, not 4,812 problems. This is not
  cosmetic: an undeduplicated repeating failure once wrote over seven hundred
  thousand rows and took the database offline.
- **Each row records which store it failed against.** A push that failed is
  always filed against one specific store, never all of them. Read that column
  before you go looking — a failure on one store tells you nothing about the
  other.

Nothing here is ever deleted. Resolving or dismissing changes a status and stamps
who did it; the row stays as an audit trail.

## Check 1: is it an unmapped location?

An order arrived from a place on the store that has no counterpart here.

This is the one to fix first. Until the two are connected, every future order from
that location fails the same way, and the app falls back to your default warehouse
— which quietly deducts stock from the wrong place.

### Fix it

1. Open the group. Where it can, the app resolves the store's own name for that
   location and shows it above the raw identifier.
2. Choose the location in this app that it corresponds to.
3. Save the mapping.

Two things to be clear about afterwards. The mapping applies to **future** arrivals
only — orders already recorded keep the fallback location they were given, along
with any stock movements written against it. And if those earlier orders moved
stock out of the wrong place, correcting that is a stock count or a transfer, not
something this page can undo.

## Check 2: is it an unknown product code?

Something sold under a code your catalogue does not contain.

Usually one of three things: the product has not been created here yet, it exists
under a different code, or the code on the store was edited after the listing was
built.

### Fix it

1. Open the group and read the code it could not match.
2. If the product genuinely does not exist here, create it first, then come back.
3. If it exists under another code, use **Map to product** and pick it.
4. Choose whether the mapping applies to one store or to both. Keep it to one
   store when the same code legitimately means different things on each.

Mapping does three things at once: it teaches future arrivals what that code
means, it closes every open error for the same code, and it fills in the missing
order lines on the past orders that mentioned it, so those orders stop looking
half-empty.

One thing it deliberately does **not** do: it does not rewrite stock history. The
original arrivals skipped their deduction, so on-hand is overstated by that
quantity until the nightly reconciliation or a stock count catches up. Backfilling
it here would risk counting the same units twice.

## Check 3: is it transient, or is it waiting for you?

Both look the same in the list. The difference is in the two timestamps, not the
message.

| Signal | What it means | What to do |
| --- | --- | --- |
| Count is 1, last seen days ago | A one-off that never came back | Dismiss it |
| Count is high, last seen days ago | It was a real fault, and it has stopped | Confirm the cause is fixed, then dismiss |
| Count is high, last seen minutes ago | It is failing right now, repeatedly | Fix it today |
| Count climbing fast on one store | A push is looping against a broken target | Escalate — this is the shape that fills disks |

A message that names a temporary condition — a timeout, a rate limit, a refused
connection — is a transient failure and will usually clear itself on the next
attempt. A message that names something missing — an unknown code, an unmapped
location, a product linked to a channel with no push target — will never clear on
its own, however long you wait. Read the message and ask: does this describe a bad
moment, or a missing thing?

One message deserves naming, because it looks like a fault in the sync and is
actually a setup gap: a product that this app shows as syncing, but which has no
push target behind it. Nothing was ever attempted, so nothing else appears to be
wrong. Re-run the channel match for that product.

## Closing errors in bulk

Three tools, in increasing order of bluntness.

- **Resolve** on one row means "I fixed the underlying cause." Use it when you
  did.
- **Dismiss all** on a group closes every unresolved error for that one target —
  the right move for a code that has been deleted on the store and will not
  recur.
- **Re-check all** walks every unresolved error and re-runs the same matching
  the live pipeline uses. Anything whose target now exists is closed
  automatically; everything else stays for you. Run it after creating a batch of
  products or filling in mappings, because historical errors are records of past
  failures and do not close themselves.

There is also a sweep for order lines that were left without a product because the
code was unknown at the time. If that count is above zero after you have mapped
some codes, run it.

## When an error will not clear

If you have mapped the target, re-checked, and the group is still there, one of
three things is true.

The mapping was saved against the wrong store, so the errors on the other store
never matched it. The code differs from what you mapped by something invisible —
a trailing space, a different dash, a case difference. Or the failures are still
arriving, in which case the count keeps climbing and the "last seen" time keeps
moving, and you are looking at a live problem rather than a stale record.

If none of those fit, capture the exact message, the store column, the first-seen
and last-seen times, and the occurrence count, and pass them to whoever
administers your sales channels. Those five fields are enough to diagnose it
without access to the page.

## Explore

**When your store and this app disagree on a quantity.** The direction of the
difference decides whether it fixes itself or needs a push.
[Learn more →](/help/sync/ops-and-my-store-disagree)

**A product shows 0 online but you still have stock.** A missing link, an
unmapped location, or an update still in the queue.
[Learn more →](/help/sync/product-shows-zero-online)