How do you find out an integration broke before the client does?
You monitor outputs, not uptime. Four checks catch most failures: freshness (did anything arrive in the expected window), volume (is today's count inside a normal range), completeness (are required fields still populated), and reconciliation (does a source count for a closed period match yours). Any failure should reach a human, not quietly produce a smaller number on a dashboard.
Broken integrations rarely throw errors
The dramatic failures are the easy ones. A crashed job pages somebody. What actually hurts is the integration that keeps running and returns less: a revoked scope that turns into empty result sets, a pagination bug that drops the tail of every pull, a renamed field that now parses as null.
Every one of those produces a successful run and a smaller number. Uptime monitoring says everything is fine, because technically it is.
The four checks worth building
- Freshness. Time since the last successfully processed record per source. Alert when it exceeds the expected interval plus a margin.
- Volume. Compare today's record count against the trailing median for the same weekday, not the average. Service businesses have weekday shapes that averages smear.
- Completeness. Track the null rate on the fields your reporting depends on. A field that was ninety-eight percent populated and is now half populated is a vendor change, not a slow week.
- Reconciliation. Ask the source for its own count over a closed window and compare. This is the only check that proves completeness rather than inferring it.
Make staleness visible to the reader
Monitoring should not be a private engineering concern. Every dashboard and every automated report should carry a data-through timestamp per source, so the person making a decision can see that call data is current while ad spend is a day behind.
And when a source is missing, show it as unknown rather than as zero. Zero is a claim about the business. Null is a statement about the data. Conflating them is how a broken feed turns into a decision about staffing, which is why our automated briefs name their sources and their cutoffs explicitly.
Tune thresholds so alerts stay believable
An alert that fires every Monday because Monday is busier teaches everyone to ignore alerts. Baselines need to be seasonal and weekday-aware, and the thresholds need a review after the first month of real traffic.
The goal is a small number of alerts that are almost always real. That discipline is part of operating an integration platform rather than merely installing one, and it is the difference between reporting that is trusted and reporting that gets quietly replaced by a spreadsheet.
Topics: monitoring · data quality · alerting · integration maintenance
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.