How Do You Troubleshoot a Sync That Stopped Working Between Two Business Systems?

Detailed Explanation

A sync between two business systems can fail in two different ways, and they need different responses. A hard failure stops entirely and usually shows up in the platform's run history or an error notification — see how do you stop an automation from failing silently for making sure that notification actually reaches someone. A soft failure is worse to catch: the sync keeps running, reports success, and quietly stops moving the records it should, or moves the wrong data — often noticed only when someone spots stale information days or weeks later.

Whichever form it takes, the underlying cause is almost always one of four things, and checking them in order finds the answer faster than guessing:

The Four Most Common Causes

1. An expired or revoked authentication token. OAuth tokens and API keys expire on a schedule, or get revoked when a password changes, an admin rotates credentials, or a security review disconnects an app that "hasn't been used recently." This is the single most common cause of a sync that was working and then simply stopped — check the connection's authentication status in the sync platform first, before investigating anything more complex.

2. An API rate limit. Every platform's API caps how many requests it accepts in a given period. A sync that ran fine at low volume can start silently failing or queuing requests once record volume grows past that limit — the symptom is usually partial or delayed data rather than a hard stop, which makes it easy to miss initially. Check the connected platform's API documentation for its current rate limits and compare against your actual sync volume; see what are API rate limits, and why do they break your automations for what's actually happening and how to design around it.

3. A changed field, object, or schema on one side. A CRM field gets renamed, a required field is added, or a picklist's allowed values change, and the mapping the sync was built against no longer matches. This is especially common after either system runs a platform update or a well-meaning admin "cleans up" field names without checking what depends on them.

4. A filter or condition quietly excluding records it used to include. A sync scoped to "only active customers" or "only deals over $X" keeps working technically, but silently stops moving records the moment something upstream changes what counts as active, or a status value gets renamed — the sync isn't broken, it's just correctly following a rule that no longer matches reality.

A Systematic Way to Isolate the Cause

1. Check the connection's authentication status first. Most platforms show a clear "reconnect" or "authentication expired" indicator on a broken connection — this single check resolves a large share of "sync stopped working" cases in under a minute.
2. Compare the run history's record counts against expectations. A run that reports success but processed zero or unusually few records points at a filter or rate-limit issue, not a hard failure.
3. Manually test the sync against one known record. Pick a specific record that should sync and trace it through manually — this isolates whether the issue is authentication (the whole sync fails), mapping (the record syncs but with wrong or missing fields), or filtering (the record doesn't sync at all despite meeting the intended criteria).
4. Check both systems' recent change history, not just your own. A schema change, a renamed field, or a revoked permission on the other system's side won't show up by reviewing only the sync configuration you control.
5. Once fixed, check for a backlog of records the broken window missed. A sync that silently failed for two weeks needs a catch-up run for whatever it missed during that window — fixing the cause going forward doesn't retroactively sync what was already dropped. If the sync didn't just miss records but actively wrote wrong ones during that window, that's a different, higher-stakes problem — see how do you clean up after an automation writes bad data to your systems.

Things to Consider

• A sync that failed silently for a while often needs a data-quality check afterward, not just a fix. If records were missed or partially synced during the broken window, clean up the resulting gaps before assuming everything downstream is now accurate.
• A broken sync's downtime window is exactly where duplicates get created once it's fixed. Reconnecting a sync that was down for a while can trigger a backlog of records all being re-evaluated at once — make sure duplicate-prevention matching logic is solid before letting a large catch-up run loose.
• Document the fix, not just the symptom. A sync that breaks the same way twice because the root cause (a rate limit, a schema dependency) was never written down wastes the same diagnostic time a second time — a short note on what broke and why saves real time on the next occurrence.
• A sync that breaks repeatedly for the same underlying reason is a signal to redesign, not just re-fix. If a filter keeps drifting out of sync with a status field that changes often, the more durable fix is usually a more stable trigger condition, not another manual correction.
• Troubleshooting gets harder once there are more than two systems involved. When several point-to-point flows touch the same data, isolating which flow actually caused a discrepancy takes longer than diagnosing a single pairing — see how do you connect more than two business systems without the integrations turning into a mess for why the whole integration set needs its own design once you're past a couple of connections.
• A sync that's running without error but producing wrong dates or times is a different diagnosis. See why do dates and times come out wrong when syncing data between two business systems for that specific, narrower failure mode rather than the causes above.

Common Mistakes

• Assuming the sync platform itself is broken before checking the connection and mapping. The platform is rarely the actual cause — an expired token or a changed field on one of the connected systems accounts for the large majority of "sync stopped working" cases.
• Fixing the immediate symptom without checking for a backlog. A sync down for days or weeks left a gap; restoring the connection going forward doesn't automatically backfill what was missed during the outage.
• Not checking the other system's admin activity or changelog. Troubleshooting only your own configuration misses causes that originated on the other side entirely.
• Reconnecting a long-broken sync without reviewing duplicate-prevention logic first. A large catch-up run after an extended outage is exactly the scenario most likely to create duplicates if the matching logic wasn't solid to begin with.