Integration monitoring: technical metrics and alerts

An integration can be failing for days before anyone notices. The symptom is almost never a total, obvious outage: it is usually an order that never reached the ERP, a product with badly synced stock or an invoice that was never generated. Isolated errors, invisible one by one, that pile up until they become a big problem.

This article reviews which metrics, alerts and dashboards are worth having to monitor integrations between ecommerce and ERP, so those errors are detected in minutes and not in weeks. It focuses on the technical layer; the business indicators (sales, stock, orders and invoicing) are covered in the article on real-time integration dashboards.

Quick summary

• Integration monitoring does not measure whether the systems are up: it measures whether the data is arriving correctly.
• The four base metrics are latency, error rate, stalled transactions and stock discrepancy.
• An alert nobody attends to is worse than no alert: it trains the team to ignore the channel.
• The question that organises the whole design is: do we find out before the customer does?

Why monitoring tends to be left for later

When an integration is implemented, the priority is making it work. Monitoring, knowing whether it keeps working well over time, is left as a secondary task, until a big error forces a review of what happened and it turns out it had been going on for a while, on a smaller scale.

There is a factor that makes the problem worse: integrations fail partially. They do not go down entirely; they process 98% of transactions correctly and fail on 2%. That 2% generates no visible signal in the system, but it does generate customers who complain, stock that does not add up and invoices that are missing.

Which metrics to monitor

Metric	What it measures	When to worry
Latency	Time a piece of data takes to travel between systems	Sustained growth, even within the limit
Error rate	Failed transactions over the total	Any increase relative to the baseline
Stalled transactions	Records that did not move on in status	Any case beyond the expected time
Stock discrepancy	Difference between channel and real stock	Beyond the margin defined per category
Retries	Times a process repeated before completing	An increase, even when the final result is successful
Pending documents	Invoices or credit notes unissued or unlinked	Any case outside the normal timeframe
Processed volume	Transactions per period	Unexpected drop relative to the usual pattern

The last metric is the most underestimated. An integration that stops receiving data does not generate errors: it generates silence. Without an alert for a volume drop, that silence can last days.

And the retries metric is the best early signal available: an increase in retries with a successful final result indicates something is degrading before it starts to fail.

Which alerts are worth configuring

• By error threshold: notify when the rate exceeds a defined percentage, not only when everything fails.
• By stalled transaction: if an order does not move on in status within the expected time, raise it before the customer complains.
• By an outage in a connected system: distinguish an integration error from an outage of the source or destination system, so as not to diagnose in the wrong place.
• By stock discrepancy: when the difference between two systems exceeds a tolerable margin.
• By absence of traffic: when a flow that normally processes transactions stops doing so.
• By pending documents: invoices unissued after a defined timeframe.

How to avoid alert fatigue

An alert that fires every day and that nobody attends to stops being an alert. Four criteria prevent that decay:

1. Every alert has a named recipient, not a generic list.
2. Every alert has an associated action. If the expected response is “look and do nothing”, it should be a metric, not an alert.
3. Thresholds are calibrated on real data, not on default values. It takes a few weeks of observation before setting them.
4. Alerts are reviewed periodically. The ones that fire often and never require action are adjusted or removed.

A good health indicator for the monitoring system: what percentage of the last month’s alerts led to a concrete action. If it is low, the system needs calibration.

What an integration dashboard should show

A good dashboard does not show every possible data point: it shows the indicators that make it possible to answer, in seconds, whether the operation is working right now. Specifically:

• Overall status of each active integration, with a simple health indicator.
• Recent errors with their cause and the system where they happened, not just the count.
• Stalled transactions with their age, ordered by waiting time.
• Comparison of synced versus real stock, per channel.
• Latency trend over the last few days, to detect degradation.
• Documents pending issuance or linking.

The detail of how to structure that view for different profiles is developed in the article on real-time integration dashboards.

Who should receive what

A frequent cause of undetected failures is that the alert reaches someone who cannot resolve it:

Profile	What they need to see	With what urgency
Technical team	Errors, latency, retries, root cause	Immediate
Operations	Stalled orders, stock discrepancies	Same day
Customer support	Status of a specific order	On demand
Finance	Pending documents, reconciliation	Daily
Management	Overall trend and volume	Weekly

Frequently asked questions

What is the difference between monitoring systems and monitoring integrations? System monitoring answers whether each platform is available. Integration monitoring answers whether the data is getting from one system to another, complete and on time. Every system can be operational and the integration can still be failing.

What is an acceptable error rate? There is no universal number. What matters is your own baseline and how it evolves: a flow that historically fails on 0.2% of transactions and moves to 1% has a problem, even if 1% sounds low. For critical flows such as invoicing, the reasonable goal is that no error is left unresolved.

Can a custom-built integration be monitored? Yes, but it has to be instrumented explicitly: log every transaction, expose metrics and define alerts. It is additional work that an integration platform usually brings solved, and that in custom development is frequently postponed.

How often should the metrics be reviewed? Alerts work in real time; the dashboard is consulted daily in the operation; the trend is reviewed weekly to detect gradual degradation. The weekly review is the one that prevents the most problems and the first one to be abandoned.

What do you do with errors that resolve themselves on retry? You log them anyway. An error the retry resolves is not a problem today, but its growing frequency anticipates one. Ignoring them removes the best early signal available.

Integration monitoring checklist

• Are the latency and error rate of each critical integration measured?
• Is there an alert for the absence of traffic in flows that normally process data?
• Are there automatic alerts for stalled or failed orders?
• Is the difference between synced stock and real stock monitored?
• Does every alert have a named recipient and an associated action?
• Does the team find out about an error in minutes, or only when the customer complains?
• Is there a centralised dashboard, or is each system reviewed separately?

You may also be interested in reading:

• “Integration dashboards: how to measure sales, stock, orders and invoicing in real time” • “OMS in retail: what data it must sync with ERP, POS and the online store to avoid stalled orders” Weavee’s Universal Connection includes monitoring, per-transaction traceability and configurable alerts on every flow, to detect a stalled order, an invoicing error or a stock discrepancy before it reaches the customer.