Your Integration Is Broken. Your Customer Knows. You Don't.

The way most teams find out

A customer messages you that their data stopped syncing. Or their invoices stopped generating. Or their Slack notifications went silent three days ago and they only just noticed.

By the time that ticket lands in your inbox, the failure has been running for hours. Maybe longer. The customer has already lost trust in your product. And now your support team is doing incident response instead of helping people get value.

This is not a rare edge case. It is the default experience for most SaaS teams that have integrations with third-party services.

Why integrations fail silently

When your own API goes down, you have an uptime monitor. Something pings the endpoint every 30 seconds and fires an alert when it stops responding. Simple.

Integrations are different. The failure does not happen on your server. It happens during a handoff. A webhook gets delivered to your customer's endpoint and returns a 404 they never told you about. An OAuth token expires for one specific tenant. A third-party API starts returning 503s but only for certain request types.

Your service is technically healthy. Your uptime check passes. But things are silently breaking in the background for your customers. Nothing in your infrastructure flagged it because nothing in your infrastructure knew about it.

The 401 problem

Take a 401 error. On a normal day, you might see a handful of them. Wrong credentials, a test request, someone poking around the API. Not worth waking anyone up.

But sometimes a 401 means your entire OAuth token refresh pipeline is broken. Now every customer whose token expires in the next hour will fail silently. That might be 3 customers. It might be 200.

The error looks identical in your logs whether it is one stray request or a platform-wide auth failure. Without the right context, you cannot tell the difference until the support tickets start coming in. And by then you are already behind.

How many customers are actually affected?

Even when you do catch a failure, the next question is usually the hardest one: who is affected?

If you have 50 customers using your payments integration and webhooks start failing, you need to know immediately whether it is one customer or all of them. Is it limited to a specific configuration? A specific tenant? Something you pushed in the last deploy?

Most teams answer this question manually. They grep logs. They look at error tracking tools. They try to piece together a picture from scattered signals across a few different systems. This takes 20 minutes minimum, often longer, and every minute you spend figuring out the blast radius is a minute your customers are getting nothing.

The noise problem

The instinct once you realize you are missing failures is to alert on everything. Log every 5xx. Send a Slack message for every webhook error. Set up a notification for every non-200 response.

This works until it does not. Within a week you have a channel that fires 40 times a day. People mute it. The on-call rotation becomes exhausting. And when a real incident happens inside all that noise, it is genuinely easy to miss it.

Good monitoring is about signal, not volume. You need to know when a pattern of failures crosses a threshold that actually matters, not when a single request fails. The difference between one 503 and ten 503s in three minutes is the difference between a blip and an incident.

Nobody tells you when it is fixed

There is a problem that does not get talked about enough: the recovery problem.

When an integration fails, your team drops everything and starts investigating. You find the issue, fix it, deploy. But how do you actually confirm it is resolved? You check the logs manually. You wait and see if any more tickets come in. You tell the customer to try again and hope for the best.

There is no official end to the incident. It just kind of fades out. The on-call engineer moves on to something else. But nobody confirmed that every affected customer is actually back to normal. You just stopped hearing about it and assumed that means it is fine.

What good monitoring actually looks like

The pattern you need is simple to describe but genuinely hard to build yourself.

First, you need to distinguish between isolated errors and patterns. A single 500 is not an incident. Ten 500s from the same integration in five minutes probably is. Your monitoring needs to understand that difference automatically, without someone writing a custom rule for every error type.

Second, you need blast radius tracking. When an incident opens, you should immediately know which customers are affected and watch that list update in real time. Not 20 minutes later after someone has had time to grep.

Third, you need a proper lifecycle. Incidents should open when a pattern is detected, move into recovery when the errors stop, and close when the system has been stable long enough to confirm it. Not because someone manually clicked a button, but because the system tracked the signal and made the call.

Fourth, and this is the one people forget, you need recovery alerts. Knowing when something broke is half the job. Knowing when it is actually fixed, for real, for all affected customers, is the other half.