What to monitor
Four metrics that catch the majority of integration failures.
These are the signals that break when an integration breaks. Monitoring all four takes more effort than monitoring one, but the coverage it provides is worth it for any integration that matters operationally.
Metric 1
Volume: are records still flowing?
The most fundamental integration metric is volume: how many records passed through in the last hour, the last day, the last week? A sudden drop to zero is the clearest signal that something is wrong. A gradual decline may indicate a filtering problem or a source system change.
Set a baseline from the first two weeks of live data. Alert when volume drops below 50 percent of the baseline for a period longer than expected. The expected period depends on the integration, a real-time webhook might alert after five minutes; a nightly batch might alert after 26 hours.
Metric 2
Error rate: what proportion of records are failing?
Some error rate is normal for any integration that processes varied real-world data. An error rate of one or two percent may represent legitimate edge cases that the integration correctly rejects. An error rate of 20 percent represents a problem, either the data contract has broken or the receiving system has changed.
Alert when the error rate exceeds a threshold that you define based on what is normal for this integration. A threshold of five percent is a reasonable starting point for most integrations. Any error above the threshold should go into a queue that someone reviews, not into a log that nobody reads.
Metric 3
Latency: is the integration running on schedule?
For scheduled integrations, latency is the gap between when the integration was supposed to run and when it actually ran. A batch integration that is supposed to run at 02:00 but is still processing at 08:00 may have stalled. A real-time webhook that is supposed to deliver within one second but is taking ten minutes has a throughput problem.
Alert when latency exceeds twice the expected duration. This catches stalled processes before they cascade into downstream failures.
Metric 4
Downstream validity: is the output correct?
Volume, error rate, and latency can all look normal while the integration produces incorrect output. The record counts are right. The error rate is low. The timing is on schedule. But the data that arrives in the destination system is wrong because a field mapping broke silently.
Downstream validity checks are the hardest to build but the most worthwhile for critical integrations. Sample a percentage of output records and verify that the key fields are populated correctly. Alert when the validation fails. This catches the class of failures that every other monitoring metric misses.
Calibrating to the integration
How much monitoring is enough, and what the answer depends on.
Not every integration needs the same level of monitoring. The right level depends on what happens when the integration fails and how long the failure would be tolerable before it becomes a serious problem.
How much monitoring is enough
Matching monitoring to operational importance
Low criticality (tolerable failure window: days): Volume check once per day. Email alert if volume drops to zero. No real-time monitoring needed. Example: a weekly report sync that populates a dashboard nobody acts on daily.
Medium criticality (tolerable failure window: hours): Volume and error rate checked hourly. Slack or email alert if either exceeds threshold. Error queue reviewed daily. Example: a CRM sync that keeps the sales team's records current.
High criticality (tolerable failure window: minutes): Real-time volume and error monitoring with immediate alerting. Downstream validity checks on a sample of every batch. Named on-call owner who responds to alerts. Example: an order processing integration where failure means customers don't receive what they paid for.
The most common gap
Most integrations are monitored for errors thrown. Not for the silence when they stop running entirely.
Error-based monitoring only catches failures that throw errors. The silent ones, a scheduler that never fired, a webhook endpoint gone offline, raise no error at all, so only watching for missing activity will catch them.
The check that lies
A check that fails open without a trace is worse than no check.
The same silence that hides a broken integration can hide a broken monitor. A guard that quietly allows on error, or a validity check that stopped running, reports healthy while nothing is actually being watched. Give the monitoring the discipline you gave the integration.
Decide fail-open or fail-closed per guard, on purpose. An access check should deny on error; a volume or cost check should usually allow on error, so a counter outage does not lock out real traffic. The direction is a property of the specific check, not a house default.
Log every bypass. When a guard fails open, record it, so a silently-degraded check is visible rather than invisibly absent. An allow-on-error you cannot see is the same blind spot as no monitoring at all.
Keep monitoring off the critical path. A telemetry outage must not fail the integration it watches. Run the metrics, sampling, and alerts as side effects, so their failure degrades observability, never the work itself.
Common questions
Questions about integration monitoring
Volume monitoring with a threshold alert. Count how many records passed through in the last period, compare it to a baseline, and alert when it drops below 50 percent for longer than expected. This catches the most common integration failure, the integration that stops running entirely, and requires only a few hours to set up. Add error rate monitoring once volume monitoring is in place.
Error monitoring catches failures that produce errors. It does not catch failures that produce silence, the integration that stops running without throwing an exception, the batch that never starts because a scheduler failed, the webhook endpoint that went offline. Volume monitoring catches this second category. Most critical integration failures in production are from the silence category, not the error category.
Run the integration in production for two weeks before setting alert thresholds. Collect the daily volume, error rate, and latency data. Calculate the mean and the standard deviation. Set alert thresholds at two standard deviations below the mean for volume and two standard deviations above for error rate. This gives you a baseline that reflects how the integration actually behaves rather than how you expected it to behave.
