The most common way a CRM integration fails is silently. Nothing crashes. A token expires, a field is renamed, a rate limit trips, and records simply stop moving. Days later a sales manager notices that no new leads have appeared, or finance finds invoices that never matched an account.
When several CRM platforms and tools are stitched together, the number of places this can happen multiplies. Monitoring is how you hear about it first.
Monitor Outcomes, Not Just Uptime
A green status light on an integration platform tells you the job ran. It does not tell you the job did anything useful. In practice, the most valuable checks look at results:
- Freshness. When did the last record successfully arrive in each direction? If the newest synced contact is two days old on a system that normally gets dozens a day, something is wrong even if no error was logged.
- Volume. Compare today’s record counts with what is normal for this day of the week. A sudden drop or spike deserves a look.
- Failure rate. How many records were rejected, and why?
- Backlog. Is a queue growing instead of draining?
- Reconciliation. Do totals agree between systems for a chosen slice, such as yesterday’s new accounts?
Freshness and volume checks catch the silent failures that error alerts miss, because they notice the absence of activity.
Alert on What Someone Can Act On
Alert fatigue is real. If the channel gets fifty messages a day, people mute it, and the one that matters is lost. Separate signals into levels:
| Level | Example | Response |
|---|---|---|
| Page now | Lead-capture sync stopped during business hours | On-call person acts immediately |
| Same day | Failure rate elevated, a subset of records rejected | Owner investigates within the day |
| Review weekly | Slow drift in duplicate count, minor warnings | Reviewed in the regular ops meeting |
Each alert should say what broke, what is affected, and link to the runbook. “Job 4471 failed” is not an alert, it is a puzzle.
Decide who owns each integration and who is the backup. An alert that goes to a shared mailbox nobody reads is the same as no alert.
Write Runbooks While You Are Calm
A runbook is a short, specific document: symptoms, likely causes, how to confirm, how to fix, how to verify, and who to escalate to. Write them for the failures you can already predict:
- Authentication expired or revoked, including when a staff member’s account was used and then disabled
- API rate limit reached
- A field or object changed in one platform
- A vendor outage on either side
- Duplicate or looping updates between two systems
Include how to reprocess failed records safely. Replaying a batch blindly can create duplicates or overwrite newer edits, so say exactly how to do it and what to check afterward.
Test the runbook by having someone who did not write it follow it once. You will find the missing step.
Running an Incident
When something breaks, the first job is to limit the damage, not to find the root cause. Pause the affected sync if it is corrupting data, tell the affected teams plainly what is known, and keep a running log with timestamps. Assign one person to coordinate communications so the technical people can focus.
Afterwards, hold a short blameless review: what happened, how it was detected, how long it took to notice, what to change. The question that pays off most is usually “how could we have known earlier?”, which feeds straight back into your monitoring.
Use Vendor Status and Change Notices
Subscribe to each platform’s status and release notifications. Many integration breaks trace to a vendor-side change, such as a deprecated endpoint or a renamed field, announced weeks earlier. Put a person in charge of reading those notices, and check the vendor’s current documentation for how deprecations are communicated.
A Hypothetical Example
Imagine a team syncing web-form leads from a marketing platform into a sales CRM. One Monday the credential used by the integration expires. No error alert fires because the platform reports the job as skipped. A freshness check, set to warn when no new lead has arrived for a few hours on a weekday, fires at mid-morning.
The on-call engineer opens the runbook, finds the authentication section, renews the credential, replays the skipped window using the documented procedure, and confirms counts match. The sales team hears about it from the ops lead before they notice anything missing. The review adds a calendar reminder for credential expiry.
Keep a Simple Map
Maintain a diagram or table of every integration: source, target, direction, owner, schedule, and runbook link. In an incident, the first few minutes are often lost working out what depends on what.
Frequently Asked Questions
What is the minimum monitoring we should have? A freshness check and a failure alert for each integration that touches revenue or customer communication, each with a named owner.
Should the integration platform’s own alerts be enough? They are a good start, but they typically report job-level problems. Add outcome checks that look at the data itself.
How do we avoid alert overload? Tie every alert to an action, group related ones, and review the noisiest weekly. Delete or downgrade alerts nobody acts on.
Who should be on call? Whoever can actually fix the integration, which may be IT, a platform team, or a CRM administrator, with a clear backup. Match hours to when the business depends on the data.
How often should we test our runbooks? Whenever the integration changes materially, and at least periodically, by walking through a scenario with someone unfamiliar with it.
Next Step
Pick your single most business-critical integration, add a freshness check with an owner, and write its first runbook this week.
By CRMCloudPilot Editorial · Updated November 4, 2026
- CRM monitoring
- integration alerts
- incident response
- runbooks