Stock not syncing between channels
Channel A changed and Channel B still shows the old quantity. Keep this page open while you investigate. Do not start by forcing a full sync or editing both sides: freeze one affected item, work through the steps in order, and verify before you close the incident.
10-minute incident runbook
- 01
Capture one exact sellable item
Write down one concrete example before changing anything. “Inventory is broken” is not diagnosable. “Variant BLUE-M, expected 2; Shopify observed 2 at 14:06; Etsy observed 4 at 13:42; last sale 13:55” is.
- 02
Confirm shared identity
Are these exact sellable units really the same inventory? Check variant/listing level. A matching title or familiar SKU is not enough when duplicates, bundles, or variants exist. If you are unsure, check whether the two values are actually comparable.
- 03
Confirm the intended quantity
Identify the system or process that owns the sellable count. If you cannot say what the target should be, do not “fix” the channel yet.
- 04
Compare observation times
If Channel B was last observed before the sale or adjustment, the first problem is stale evidence. Refresh or re-read it before declaring a current mismatch.
- 05
Check connection state
Expired credentials, revoked permissions, an unavailable source, or a broken OAuth grant can stop new reads or writes while older catalog evidence still exists.
- 06
Check the last operation
Did the relevant read or write fail, retry, time out, or complete? Separate execution status from the catalog value you see afterward.
- 07
Check write capability and direction
A connection may be read-only. A connector may write only one direction. Confirm that the system you expect to repair Channel B is actually allowed to write Channel B.
- 08
Check intentional channel policy
Buffer stock, maximum quantity, reserved stock, or channel allocation can make different values correct. Compare the observed difference with the configured policy.
- 09
Check competing writers
Look for direct marketplace edits, another connector, returns, cancellations, imports, POS adjustments, or a second inventory tool that could have written after the expected update.
- 10
Verify after correction
Re-read both channels, record the new observation times, and confirm the exact affected variant or listing, not only the parent product.
Classify the incident before choosing the fix
- Identity problem
- The listings do not represent the same sellable unit, or the mapping is wrong.
- Freshness problem
- One value is older, so the current state has not been observed yet.
- Execution problem
- A read, write, queue job, retry, or API call failed or did not finish as expected.
- Capability problem
- The expected write path is read-only, one-way, or unsupported.
- Policy difference
- The values differ because a buffer, cap, reservation, or allocation intentionally says they should.
- Competing writer
- Another process changed the value after the normal path ran.
Those incidents need different fixes. Re-running a sync cannot repair a wrong mapping. Editing a stale channel manually can hide an authentication failure. Forcing quantities equal can break an intentional buffer.
Before you close the incident
- Check other items touched by the same failed connector, credential, queue, or time window.
- Record the incident class and the smallest permanent correction.
- Decide what should surface automatically next time: stale evidence, failed operation, mapping review, or another explicit exception.
Where GNIZDO fits in the runbook
For connected channels, GNIZDO can supply the evidence for steps 2, 4, 5, and 6: confirmed shared identity, per-channel observation times, connection state, and the result of the latest collection. It does not automatically synchronize inventory, and it does not decide which value should win.