A customer calls about an invoice they never received. Your team checks the ERP — the order is there. They check the fulfillment system — nothing. Somewhere between the two, a message vanished three weeks ago, and nobody knew because nothing was on fire. The dashboard was green. The sync was "working."
This is the most common integration failure we see, and it has nothing to do with the code quality. The integration did fail, briefly and unremarkably. What went wrong is that the failure was invisible, and once it was invisible it became permanent.
Failure Is Normal. Silence Is the Defect.
Every system you connect will go down, time out, rate-limit you, rotate a credential, or receive a record with a character it doesn't like. Your payment processor will have a maintenance window. Someone in accounting will paste an address with a line break in it. A vendor will ship an API change with a short notice period.
None of that is preventable. What's entirely in your control is whether a failure announces itself and whether the work can be recovered. Teams spend their integration budget trying to make the happy path elegant and spend almost nothing on the unhappy path — which is where the actual business risk lives. An order that never syncs doesn't look like an outage. It looks like a confused customer and a revenue number that's slightly wrong for reasons no one can explain.
Four Questions Every Integration Should Be Able to Answer
Before you connect two systems, make sure someone can answer these in plain language:
- Where does a failed record go? Not "it errors out" — where, physically, does it sit so a human can find it? A queue, a table, a log you can actually search.
- Who finds out, and how fast? A notification to a person or channel that owns the outcome, not a log entry nobody reads.
- How does the work get re-sent? Can an operator retry one record without a developer, or does recovery require a deployment?
- How do we know nothing is stuck right now? Something that proves the absence of problems, not just the absence of alarms.
If an integration can't answer all four, it isn't finished. It's a demo that happens to be running in production.
Retries Only Help If Repeats Are Safe
The standard fix for a timeout is to try again. That's correct, but it introduces a second problem: you often can't tell whether the first attempt actually failed or just failed to report back. If the receiving system already created the invoice and your retry creates a second one, you've traded a missing record for a duplicate — which is harder to clean up.
The technical term is idempotency, and the plain version is this: every message carries a unique reference, and the receiving system is built to recognize a reference it has already processed and acknowledge it without doing the work twice. That one design choice is what makes aggressive retries safe instead of dangerous. Without it, teams get nervous about retrying anything, and manual re-keying creeps back in as the recovery strategy.
Reconciliation Beats Monitoring
Monitoring tells you something broke. Reconciliation tells you whether your systems currently agree — which is the question your CFO is actually asking.
A reconciliation check is unglamorous and enormously valuable: count the orders created in the storefront yesterday, count the orders that landed in the ERP, and report the difference. Do the same for invoices, payments, inventory adjustments, and new customer records. When the numbers match, you have evidence, not a feeling. When they don't, you find out in a day instead of at quarter close.
This is also the control that catches the failures monitoring misses entirely — records rejected silently by validation rules, updates applied to the wrong record, or a job that stopped running without crashing. Build the daily count before you build the fancy dashboard.
Give Every Connection an Owner
Integrations rot because they belong to no one. The consultant who built the connector moved on, the operations lead assumes IT watches it, and IT assumes operations would say something.
Assign each integration a named business owner — not a technical owner, a business owner. The person accountable for "orders reach fulfillment" should be the person who gets the alert. They don't need to fix it themselves. They need to care that it's broken. Pair that with a documented runbook of what to check first and a quarterly review of credentials and API deprecation notices, and most integration surprises stop being surprises.
Build the Unhappy Path First
If you're planning an ERP, CRM, or storefront connection right now, spend the first design conversation on failure: where bad records land, who gets told, how work gets replayed, and how you prove daily that both systems agree. It adds modest effort up front and removes the category of problem that costs the most to unwind later.
If you're already living with syncs you don't fully trust, that's a solvable problem and usually a faster one than people expect. Reach out to Infraxio — we'll look at how your systems talk to each other, where the silent gaps are, and what it takes to make every connection visible, recoverable, and owned.