What Happens When an Integration Stops Working?
Connecting software can eliminate manual work, but integrations can fail. Discover why monitoring, retries and clear error handling matter.
In this guideJump straight to what you need3 sections
A customer submits an order through a website. Normally, the details appear automatically in the business's order management system.
One morning, they don't.
The website still works. Customers continue placing orders. The internal system looks normal. Nobody notices that the connection between them has stopped transferring information.
This is one of the less glamorous parts of software integration: deciding what should happen when something goes wrong.
Connected doesn't always mean reliable
Integrations allow different applications to exchange information, often without employees needing to intervene.
They can be extremely useful for transferring enquiries, updating customer records, creating invoices and keeping business information consistent.
But the systems involved are not always under the same company's control.
An application might temporarily become unavailable. An API might reject a request. An access token might expire. A required field might change, or the receiving system might refuse a record because information is missing.
None of these situations necessarily means the entire integration is badly designed.
The important question is whether the failure is handled properly.
An integration that works perfectly during testing but silently loses information during an outage can create more uncertainty than the manual process it replaced.
Employees may assume everything is happening automatically when, in reality, some records are no longer arriving.
Design for the days when things go wrong
Imagine a business connecting its online enquiry form to a CRM.
A customer submits a request while the CRM is temporarily unavailable.
A basic implementation might attempt to send the information once and then stop when the request fails.
A more resilient workflow could preserve the enquiry, record the failure and attempt delivery again when appropriate.
If the problem continues, the system could alert the responsible person so they can investigate.
The key is that the enquiry should not simply disappear.
Retrying also requires care. If a request succeeds but the confirmation is lost, sending it again could create a duplicate customer or enquiry.
A well-designed integration needs a way to recognise when an operation has already been completed.
This is one reason integration work involves more than connecting two API endpoints. The normal path matters, but so do failures, duplicate requests, missing information and changes to external systems.
Not every business needs an elaborate monitoring platform. Sometimes a simple error log and a notification for failed transfers are enough.
Know what success looks like
Before introducing an integration, decide how you'll know it's working.
If ten enquiries arrive through the website, should ten corresponding records appear in the CRM? How quickly should they arrive? Who checks when the numbers don't match?
These questions turn a technical connection into a dependable business process.
It can also be useful to distinguish between temporary failures and problems requiring human attention.
A brief network interruption might resolve through an automatic retry. An invalid customer record may require somebody to correct the information.
Treating both situations identically can create unnecessary alerts or repeated failures.
At Software Logic, we help businesses explore practical software integrations, including the reliability and error-handling considerations that make them useful beyond the initial demonstration.
If one of your business integrations stopped working this morning, how long would it take before somebody noticed?
Have a question about your business? Talk to Liam.
Counting readers…