Yesterday, completed jobs appeared in your billing system. Today, staff are copying them across by hand. Both applications are online, the integration says it is connected, and nobody can tell you which records are missing.
Software integration troubleshooting starts by identifying the last successful business transfer, the affected records, and the point where the exchange stopped behaving as expected. Check access, delivery, validation, mapping, and processing status before deciding what to replay.
Avoid restarting every job or importing the whole backlog immediately. A destination may have completed some actions even when the sending application reports a timeout. Repeating them without checking can create duplicate invoices, payments, notifications, or inventory movements.
The goal is to restore the workflow and account for the affected records, with enough evidence to explain what happened.
What to do first when data stops syncing
Establish the business impact before changing the connection. Identify which teams are blocked, which deadlines matter, and whether anyone has already started entering records manually.
Then capture a short incident record:
Preserve the available job history, error details, and processing position before resetting anything. Keep passwords, access tokens, payment details, and unnecessary personal information out of shared tickets and screenshots.
If continued processing could repeat financial or operational actions, have the responsible operator pause or isolate the affected step under the incident procedure. Confirm where new work will be retained so a pause does not quietly discard it. A record of manual work will also be needed when the systems catch up.
Match the symptom to the next check
Different data sync problems need different investigations. A connection that never starts is a different problem from one that processes every record twice.
| What you see | What to check first | What to avoid |
|---|---|---|
| No records have arrived since a particular time. | The schedule, connection status, credentials, permissions, and last completed business transfer. | Assuming a green job status means records reached the destination. |
| Most records arrive, but some are missing. | Eligibility filters, required fields, rejected records, batch limits, and the saved processing position. | Replaying all historical data before identifying the missing records. |
| Records arrive more than once. | Repeated deliveries, retry behavior, matching identifiers, and whether the destination already completed the action. | Deleting duplicates before checking their invoices, payments, or other dependent records. |
| The same records contain different values. | Field mappings, transformations, update timing, and which system is allowed to change each field. | Overwriting both systems without an agreed authoritative value. |
| Transfers work but fall further behind. | Queue age, rate limits, job duration, data volume, and destination processing delays. | Increasing concurrency without checking vendor limits and ordering requirements. |
Start with one representative affected record and one known successful record. Comparing their journey can reveal a specific boundary to investigate before anyone proposes a wider redesign.
Trace one record from the source to the destination
First, establish whether the record was eligible to move. A job may need a completed status, an approved amount, or a required customer identifier. A record visible in the source application is not necessarily ready for the integration.
Follow the eligible record through the exchange:
Use available record identifiers, request identifiers, batch identifiers, or timestamps to connect those stages. A successful network response can mean that work was accepted for later processing. Check the later result when the destination processes work asynchronously.
For a file exchange, verify that the expected file was created, delivered to the correct location, read, and imported. A file sitting in a folder proves only that it reached that folder. For a scheduled database exchange, check the supported query or view, access, and processing result without writing directly to application tables as an improvised repair.
Check the common causes of data sync failures
Expired credentials or changed permissions
A connection can fail after a password change, secret rotation, user departure, revoked authorization, or change to an application's permitted operations. A connector may also require renewed consent or a subscription entitlement.
Confirm the integration is using the intended account and environment. Check whether it still has the specific access the documented workflow requires. Authentication failures and permission failures need different fixes, so preserve the actual error detail.
Restore the approved access or renew the connection through the provider's supported process. Giving the integration broad administrator access to make an error disappear creates a different problem and may hide the original cause.
Vendor changes, unavailable endpoints, or network restrictions
Review vendor service notices and recent changes to API versions, endpoints, file formats, subscriptions, certificates, and network rules. Confirm the running integration uses the intended production address rather than an old or test destination.
Check what changed on your side as well. A deployment, configuration edit, firewall change, or replaced server can explain why a previously working connection stopped.
If the connection uses an authorized export, vendor tool, or another supported method instead of an API, inspect that method's specific failure points. Our article on integrating software without a public API explains those options and their operating limitations.
Records rejected by validation or field mapping
Look for a changed required field, an unfamiliar status value, a missing customer match, a longer text value, or a date or number in an unexpected format. A vendor update may expose a problem that older records did not contain.
Determine whether one invalid record blocks the entire batch or is rejected separately. Preserve the rejection details and assign someone to correct the source data or approved mapping. Skipping a record without tracking it can make the job appear healthy while leaving work unfinished.
Rate limits and growing backlogs
A rate limit means the destination is restricting how quickly requests can arrive. Other slowdowns can come from larger batches, slower queries, vendor queues, or a worker that cannot keep up with the current volume.
Check job duration, queue depth, the age of the oldest waiting item, and any retry instructions returned by the provider. Respect the provider's limits. A carefully paced recovery may work better than running many copies of the same job.
The right repair depends on the bottleneck. It could involve batching, scheduling, query work, a supported capacity change, or a different exchange design.
Broken schedules, webhooks, or processing positions
A scheduled task may be disabled, running on a retired server, or using an unexpected time zone. A webhook, which is a notification one system sends when an event occurs, may be reaching the wrong address or failing the receiving system's required signature check.
Keep the required security checks in place while correcting the delivery configuration. Investigate the delivery result and the receiving application's handling of the event.
Also inspect the saved processing position. Some integrations remember the last timestamp, record, or page they processed. Advancing that position before a transfer is durably recorded for recovery can leave records behind. Resetting it carelessly can reprocess records that already succeeded.
Conflicting updates in a two-way sync
When both applications can change the same information, establish which system owns each field and how conflicts are resolved. A correction in one system may be overwritten by an older value from another job.
Compare update order, matching identifiers, time zones, and the configured conflict rules. If the real problem is that two reports use different definitions or update schedules, our guide to conflicting business reports covers that investigation separately.
How to retry failed transfers without creating duplicates
A timeout tells you the sender did not receive a result in time. It does not necessarily tell you that the destination did nothing. Before replaying a record, check whether the intended action already exists in the destination using a reliable identifier.
Where a destination supports idempotency, repeated requests with the appropriate identifier can be handled as the same logical action. Confirm the provider's actual behavior, supported operations, and retention window. Do not assume every connector or import tool provides that protection.
Prepare an explicit recovery set: the records that failed, the records whose result is unknown, and the records already verified as completed. Resolve unknown outcomes before treating them as failures. Decide how manual entries will be matched so recovery does not duplicate staff work.
Run a small, controlled recovery first. Verify the destination results before processing a larger approved set. If transfers must happen in order, preserve that order. If a record is rejected again, retain it for review rather than letting retries run indefinitely.
For workflows involving payments or inventory, check the dependent effects as well as the main record. A duplicate row can represent a repeated business action that needs a coordinated correction.
A hypothetical example: completed jobs stop reaching billing
Imagine a maintenance company whose work-order application sends completed jobs to a separate billing system. Thirty jobs are eligible for a particular transfer, but staff can find only twenty-four in billing.
The investigation confirms twenty-four destination records by their work-order identifiers. The import report shows that the next record was rejected because its customer mapping was missing, and processing stopped before the remaining five records were attempted.
The team corrects the approved customer mapping, confirms that none of the six outstanding jobs was entered manually, and checks the destination again for matching identifiers. It then processes the six verified outstanding jobs through the supported recovery procedure.
Recovery includes confirming all thirty expected billing records and checking that the next scheduled transfer works. The longer-term repair gives rejected records a visible review queue and prevents one invalid record from blocking unrelated work where the business rules and destination support that behavior.
Other import tools may reject the whole batch, continue past invalid records, or process records in parallel. Check the actual import results before deciding which records need recovery.
How do you know a data sync problem is fixed?
An error message disappearing is only one check. Reconcile the affected work against the rules that determine what should have transferred.
Compare eligible source identifiers with completed destination results. Account for rejected records, intentional exclusions, manual entries, and work still waiting. Where relevant, verify amounts, status values, required fields, and downstream actions.
Raw record counts may differ for valid reasons. One order might create several line items, or the destination may combine transactions. Use the expected relationship between the records rather than requiring identical totals everywhere.
Watch a subsequent normal processing cycle as well as the recovered backlog. Confirm that fresh work moves, the saved processing position is correct, and the oldest waiting items are within the agreed delay.
Prevent the same integration failure from becoming a routine task
Useful monitoring should show whether the expected business work completed. Track failed and rejected records, unexpected gaps in activity, queue age, and time since the last meaningful transfer. Distinguish a legitimate quiet period from a job that stopped running.
Give every alert an owner and a response procedure. Keep the connection's credentials, vendor contacts, mapping rules, deployment history, and recovery instructions accessible to the people authorized to maintain it.
After a repair, add a repeatable check for the failure where practical. Examples include a missing customer mapping, repeated delivery, an expired authorization, or an interrupted batch. Our guide to automated regression testing explains how to prioritize checks around important business outcomes.
If failures keep recurring, review the design and ongoing workload. Our software integration cost guide explains why error handling, monitoring, vendor coordination, and support belong in the scope of a maintained connection.
Common questions about software integration troubleshooting
Why does an integration say connected when records are missing?
Connected may describe a valid login or reachable endpoint. Records can still be excluded by filters, rejected during validation, waiting in a queue, or accepted without completing downstream processing. Trace an eligible record through to its business result.
Should you restart a failed integration?
A restart may help a particular fault, but first preserve diagnostic information and check how unfinished work and completed actions are tracked. Otherwise, the restart can erase useful evidence or trigger duplicate processing.
Can Honor Tech troubleshoot an integration built by another provider?
Often, yes, when the necessary access, source or connector configuration, logs, and vendor permissions are available. The first step is to establish the supported access and scope. Some issues require cooperation from the software vendor or the original integration provider.
When should a failing integration be rebuilt?
Consider a larger change when the current method relies on unsupported behavior, cannot account for records reliably, or requires repeated manual intervention. First compare a focused repair with a redesign, including the business disruption and ongoing support each option would involve.
Get help finding where the exchange breaks
Honor Tech's systems integration service can investigate supported connections between business applications, databases, files, and vendor platforms. Ongoing monitoring and incident responsibilities can be defined through application support and maintenance.
To discuss a data sync problem, share the systems involved, the direction of the exchange, when the problem began, a description of the affected records, and the operational impact. We can use that context to define the investigation, identify required access, and recommend a repair or recovery plan your team can review.