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.
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.
- Retrying a failed integration without understanding why it broke risks the same failure recurring. An expired credential or a changed API response format is not fixed by a retry.
- Checking each integration's delivery log or connection health on a schedule, not only when something looks wrong, catches silent failures before they grow into a larger 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 constantly surface problems faster, because there are more chances to notice something missing. 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 integrations like mailbox connections, a connection health indicator surfaces authentication failures. It does not diagnose every possible cause. Some issues still require checking the provider's own status or settings.
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?
- A periodic check, commonly monthly, of each integration's delivery log or connection health catches silent failures before they grow into a larger gap. It does not rely on someone noticing something is missing.