A sync did not start, or the feed could not be reached

When a sync does not start, or the feed cannot be read, the answer is on the run, not on the connection. Open Sync history, open the run, and read the banner and counts there.

One thing to rule out: a connection's Status never changes when a sync fails. It reads Active either way, so it tells you nothing about the problem.

"Couldn't reach the supplier feed"

This banner appears on the new connection page, in the "Inventory endpoint & mapping" section, when Test connection cannot read the feed. It carries the supplier's own error text, or, when there is none, "Check the base URL, inventory path, and credentials above, then test again."

The usual causes:

• The Base URL or Inventory path is wrong. The message usually reads like HTTP 404 from ....
• The credentials are wrong, expired, or of the wrong auth type. Expect HTTP 401 or HTTP 403.
• The supplier is rate-limiting you. The message reads rate-limited (429). BigBuy publishes a limit of 10 requests per hour on its stock endpoint, so schedule it hourly at most.
• The supplier has not approved you yet. Lipsey's pre-approves caller domains and egress IPs, so ask Normalize for the addresses and submit them before your first sync.

Fix the field and press Test connection again. A test writes nothing, so repeat it freely.

On a saved connection, do this in the Credentials section of the connection page. Test connection there reports "Connection test passed" or "Connection test failed", and Save credentials stores the change. Leave a secret field blank to keep its current value.

If a real sync hits the same problem, the run is recorded as Failed and the run detail shows "Sync run didn’t complete" with the same message underneath. Do not go looking for a Fetch log on that run. A call is logged only once it comes back, so a call that never got an answer leaves no row, and the section does not render at all. A Fetch log appears when at least one call succeeded, and it lists Endpoint, Duration, Rows and Cache.

A frozen plan stops syncs before they start

If your Everstock subscription is frozen, nothing runs. Pressing Sync now or Preview changes answers "Your plan is inactive. Reactivate it to run a sync." and no run is created at all. Scheduled and catch up syncs behave differently: they do record a run, with the status Skipped and the message "Plan inactive. Sync skipped." A Skipped run is neither a failure nor a sync. Reactivate on Plans and billing and the next sync runs normally.

Queued syncs that have not started

If a queued sync sits unprocessed for more than three minutes, Everstock shows "Queued syncs have not started" on the dashboard under "Needs attention", on Sync history, and on the connection page. The body reads: "N syncs are queued and have not started, so your inventory is not being updated right now. This usually clears on its own. If it does not, contact support."

After you press Sync now or Preview changes, the connection page watches the run for two minutes. If it has not finished by then, the page stops watching and shows one of three toasts:

• "This sync is still waiting to start. Reload to check again, or contact support if it stays queued."
• "This sync is taking longer than expected. Reload to see the latest status."
• "This sync never started. Reload to check again, or contact support if it stays queued."

None of these cancel anything. The page stopped watching, the run did not. It carries on and shows in Sync history once you reload.

The run finished but nothing changed

Read the Run summary first: Fetched, Applied, Skipped, For review, Failed, and Duration. Applied at 0 with a high Skipped is the normal, healthy case: those records matched a product and were already correct. They are counted in Skipped and nowhere else. They get no row in the per record audit, so an empty table under a large Skipped count is the app working, not detail going missing.

On a Preview run nothing is written at all, so Applied is honestly 0 and every would be change is listed as Planned.

A high "For review" is the other common answer. Open the run and set the "Item status" filter to Review. Three things land there, named in the "Change" column: Unmatched (no SKU or barcode to match on), Duplicate (two supplier records shared a key), and "Not found in supplier" (a product in your store that was not in the feed). That last one is deliberate. Everstock never writes a product down to zero for being missing from a feed, so a short or empty feed sends rows to review.

Your settings can also produce a quiet run. A feed row whose quantity is blank or unreadable is skipped and your stock is left alone. Prices only move when Sync price is on, product fields only when the matching checkbox under "Product fields (advanced)" is on (all five ship off), and anything in Ignore list (optional) is dropped before the diff runs, although those rows still count towards Fetched.

A dry run with nothing to do says so, in the "Preview: proposed changes" modal: "Everything is in sync. A real run would change nothing."

Retries

A failed sync job is tried up to 5 times by default, meaning the first attempt plus four retries, with an exponential backoff starting at 1,000 ms and doubling after each failed attempt. Change both per connection under "Advanced retry" on the connection page, using "Max retry attempts (optional)" and "Retry backoff in milliseconds (optional)". Leave either blank to use the default.

Need help? Visit the support page or email hello@usenormalize.com.