What to do when an integration breaks
Check the delivery log first, not the configuration screen. A connection that looks correctly set up can still be failing silently. The log is usually where that shows up before anything else does.
Want to see it first? Book a demo
The short answer
- A silent failure, missing data rather than a visible error, is the common way an integration breaks. A lead that should have appeared did not. A webhook event that should have fired never shows in a delivery log.
- A configuration screen showing a connection as 'active' does not confirm it is working. A delivery log or event history is the reliable place to check whether events are being sent and received.
- If you retry a failed integration before you know why it broke, it'll likely break the same way again. An expired credential or a changed API response format is not fixed by a retry.
- Check each integration's delivery log or health on a schedule, not only when something looks wrong. You'll catch silent failures before they turn into a bigger data gap.
Why the configuration screen is the wrong place to look first
When an integration seems to have stopped working, the instinct is to check the settings page and confirm the connection still shows as active. That check is usually unhelpful. Most integration failures happen at the delivery level. An event fired but was not received. A token expired and requests are failing silently. They do not happen at the configuration level, where a broken connection would show an obvious error.
A delivery log, if the integration has one, shows what actually happened. Which events were sent. Whether each attempt succeeded or failed. What error came back. That is almost always a faster and more accurate diagnosis than a configuration screen that shows "active" while delivery has been failing for days.
The distinction matters most for integrations that run infrequently: a weekly sync, a monthly report export. A long gap between runs means a silent failure can go unnoticed for just as long before anyone realizes the expected data never arrived. Integrations that run all the time show problems faster, since you get more chances to spot a gap. Infrequent ones need a deliberate check, because that natural feedback loop is slower.
Common integration failure causes and how to spot them
| Cause | How it typically shows up |
|---|---|
| Expired credential or token | Delivery log shows authentication errors on recent attempts |
| Receiving endpoint down or moved | Delivery log shows connection failures or timeouts |
| Changed API response format on either side | Data arrives but is malformed or partially populated |
| Rate limiting | Some events succeed, others fail intermittently around volume spikes |
What to actually do once a break is confirmed
Check the delivery log or event history first. Identify the error pattern. Fix the root cause before retrying, rather than retrying blind and hoping the issue does not recur. If no delivery log exists for an integration, that absence is worth noting on its own. Future failures of the same kind will be harder to catch quickly.
Once a cause is found and fixed, note it somewhere the team can find later. The same category of failure, an expiring token, a rate limit hit during a specific process, tends to recur months later once the details of the first fix are forgotten. A short written record of what broke and how it was resolved turns a repeat incident into a quick fix instead of a full re-diagnosis.
Disclosure: SalesCrew is our product. Its outbound webhooks keep a delivery log with retries, which is the first place to check when a downstream system stops receiving expected events. For inbound links like mailbox connections, a health light shows when sign-in fails. The provider's own status page is the next check after that.
A quiet integration is not the same as a healthy one
Questions
- What is usually the first sign an integration has broken?
- Often a downstream absence rather than an obvious error. A lead that should have appeared did not. A webhook event that should have fired never showed up in a delivery log. Silent failures are more common than loud ones for most integrations.
- Should a broken integration be fixed by retrying immediately?
- Only after understanding why it broke. Retrying without knowing the cause can mask a recurring issue, such as an expired credential or a changed API response format. It will break again shortly after the retry succeeds.
- How often should integrations be checked proactively, not only when something looks wrong?
- Check each integration's delivery log or health once a month or so. That catches silent failures before they grow into a bigger gap. It does not rely on someone noticing something is missing.