Nine days of stale data
An agency's lettings team calls to say your product is showing tenancies that ended last week and missing properties they added days ago. Your developer looks and finds the sync with their CRM stopped nine days ago. The agency's admin changed their password, which invalidated the connection your product used. No error was shown to anyone. The sync job ran every hour, found it could not authenticate, logged a line and finished successfully.
The agency has spent nine days working with wrong information in your product, and some of it may have been sent to landlords or tenants.
Why a sync can die quietly
Integration code tends to be written for the happy path. When the CRM refuses a call, the job logs it and moves on, because crashing would be worse. The result is a system that looks healthy while doing nothing.
- Access tokens expire or are revoked when the agency changes a password, an admin leaves, or the CRM vendor changes its rules.
- The CRM's API rate limit is reached at busy times and later pages of data are silently skipped.
- A new custom field or status in the agency's CRM makes records fail validation one by one.
- Webhooks stop arriving and nothing checks that they should have.
- Monitoring watches whether the job ran, not whether data actually moved.
What quiet failures cost
The damage is out of proportion to the fault. A sync outage that lasts an hour is invisible; one that lasts a week makes your product wrong in front of the agency's clients. Negotiators start checking the CRM to confirm everything your product shows, which removes much of its value. Each incident also costs developer time, often spent working out when the sync stopped and what data needs to be caught up.
The catch-up itself carries risk. Replaying a week of changes in the wrong order can overwrite newer data with older data, and records edited on both sides during the outage need a rule about which version wins. Without a clear record of when the sync stopped and what was missed, developers make those decisions under pressure, one agency at a time.
How we build sync health you can watch
What we build measures the thing that matters: whether each agency's data is current.
- A sync health record per agency and per data type (properties, applicants, tenancies, viewings), with last successful sync, records processed, records failed and the last error.
- Freshness checks based on each agency's normal pattern: a busy agency with no property changes for a full working day is suspicious, even if every job reported success.
- Error classification: authentication, permission, rate limit, validation or CRM outage, each with a likely fix, such as reconnecting the account.
- Alerts to your support team grouped by cause, and a message to the agency admin when only they can fix it, such as reauthorising the connection.
- Catch-up runs that replay changes since the last good sync once the cause is fixed, with a count of what was brought across.
- A status panel in your product for each agency showing when data last came in, so negotiators can see it for themselves.
| Symptom | Likely cause | Who acts |
|---|---|---|
| All calls failing with auth errors | Token revoked or password changed | Agency admin reconnects |
| Some pages missing at busy times | Rate limit reached | Automatic retry with back-off |
| Records failing one by one | New field or status in the CRM | Your team updates the mapping |
| No changes for longer than usual | Webhooks stopped or CRM change | Your team investigates |
| Every agency on one CRM failing | CRM outage or API change | Your team, incident opened |
The same password change, afterwards
The agency admin changes their password on Thursday afternoon. Within the hour, the sync health check sees authentication failures and sends the admin an email explaining the connection needs reauthorising, with a link. Your support team sees the same alert. The admin reconnects on Friday morning, the catch-up run brings across the changes from overnight, and the lettings team never sees stale data.
Could a sync be dead right now?
- Your monitoring checks that sync jobs ran, not that data changed.
- Agencies have told you about stale data before your system did.
- Nobody can see at a glance when each agency last synced successfully.
- Catching up after an outage is a manual job for a developer.
- Authentication errors are logged but alert nobody.