Monitor and troubleshoot

Monitor your syncs

Know a feed broke before your buyers do: what to watch, what to alert on, and why a silent success is the failure you miss.

Integrations fail quietly, on a Tuesday, and you find out on Thursday when a buyer asks why an article that was delivered last week is still shown as available. Monitoring is what closes the gap between those two days.

The failure that hurts most

The run that hurts most is the one that succeeds with nothing in it.

A source system changes an export path. The feed connects, reads an empty file, reports "0 records processed", and finishes green. Nothing alerts, because nothing failed. Your catalog is frozen at last Monday, and it stays frozen until somebody notices.

The second version of the same problem is the run that never starts. A disabled schedule, a paused workflow, an expired credential caught at the trigger: the run list shows no failures, because it shows nothing at all.

Both lead to the same rule: monitor for expected activity as well as for errors.

What to watch

SignalHealthyInvestigate
Last successful runWithin the expected intervalOlder than one and a half intervals
Records processedIn the usual rangeZero, or an order of magnitude off in either direction
Failed rowsA stable small number, or noneA jump, or a slow week-on-week climb
RuntimeStableGrowing steadily, or suddenly halved
Webhook delivery successNear 100%Repeated 5xx, or rising latency
Failed event queueEmptyAnything in it
Punchout sessionsRegular for each live customerA customer whose sessions stopped

The last one is forgotten often and expensive. If a punchout customer's sessions stop appearing, either something in the connection broke or their buyers have gone back to phoning. Both are worth a call this week rather than at the next contract review.

Set up the alerts

  1. Go to Integrations › Workflows and open the workflow.
  2. Enable notify on failure, to a group address. A personal address is an alert that goes on holiday.
  3. Enable notify on empty result where the workflow has one. A run that processes zero records on a feed that normally moves thousands is an incident.
  4. Set a staleness alert: notify if no successful run has completed within the interval you expect.
  5. In Webhooks › Outbound, enable alerting on the failed-delivery queue.

Then send one deliberately failing run through the whole chain and confirm a human receives the mail. An alert nobody receives is worse than no alert, because it produces confidence.

The morning check

Five minutes, once a day, for the first month after any change:

  1. Open the Integrations dashboard for running jobs and recent failures, then Integrations › Runs sorted by time. Everything that should have run overnight has run.
  2. Check the record counts against the previous days. Look for zeros and for tenfold jumps.
  3. Open the failed queue for events. It should be empty.
  4. Spot-check one product and one price against the source system.

After a month this can drop to a weekly look at the trend, provided the alerts have proven they arrive.

Reconciliation

Alerts catch what breaks. Reconciliation catches what drifts, and drift is what produces the "the shop says something different from the ERP" conversation.

Once a week, compare counts rather than records:

  • Articles active in the ERP versus published here.
  • Orders transmitted here versus orders received there, for the same period.
  • Customers active there versus organisations here.

The numbers will never match exactly, and that is fine. What matters is that the gap is stable. A gap that grows by 30 every week is a rule silently dropping records, and it is far easier to find at 30 than at 3,000.

Write down the expected numbers when a feed goes live: how many records, how long, at what time. Six months later, nobody remembers whether 18 minutes and 44,000 rows is normal, and without that baseline every anomaly looks either fine or alarming, depending on who is looking.

Next