You connected your system to something — accounting software, a shipping provider, a payment service, a supplier’s catalog. It worked. Then a few weeks later it stopped, and nobody noticed until the numbers stopped matching.
Someone fixed it. Then it broke again.
At this point you have probably concluded that integrations are just fragile. They are not, particularly. What you have is a specific and very common set of problems, and they have specific fixes.
Why connections break
The other side changed and nobody told you. They did tell you, usually — in an email to a developer address that no longer forwards anywhere, six months ago. Services change how they work all the time. Well-run connections are built to notice and complain loudly. Most connections are built to assume nothing will ever change.
Nothing retries. Every network request fails occasionally. That is normal and expected. A properly built connection notices a failure, waits, and tries again a few times before giving up. Many connections try once. When that one attempt lands during the other service’s ten-second hiccup, that order is simply gone, and nothing anywhere records that it happened.
There is no record of what was sent. When you ask why an order did not reach accounting, the honest answer in most systems is that nobody knows, because nothing wrote down what was attempted. Without a log you cannot tell the difference between “we never sent it,” “we sent it and they rejected it,” and “we sent it and they lost it.” You are left comparing two lists by hand.
Nothing is watching. This is the one that turns a small problem into a large one. The connection fails on the 3rd. It is discovered on the 28th when someone reconciles the month. Twenty-five days of data are now missing and reconstructing them is manual work.
Credentials expired. Access keys and passwords for other services often have an expiry date. When one lapses, the connection stops. If nothing is watching, you find out later.
What this is costing you
Worth being concrete, because “it breaks sometimes” hides the real number.
There is the direct data loss — orders that never reached fulfilment, payments not recorded against invoices, stock counts drifting from reality. There is the staff time spent reconciling by hand, which in most businesses we see is the single largest cost and is completely invisible because it has been absorbed into someone’s normal week. And there is the decision cost: when your staff stop trusting the numbers, they stop using them, and start keeping their own spreadsheets.
That last one is the expensive one. Once your business is being run from side spreadsheets, the system you paid for is decoration.
What a reliable connection actually looks like
It is not complicated. It is four properties, and most broken connections are missing all four.
It retries. When the other side is briefly unavailable, the attempt is repeated after a short wait, then a longer one, a few times before giving up.
It records everything. Every attempt, what was sent, what came back. When something goes wrong you can answer the question in two minutes instead of two days.
It cannot lose the item. Work sits in a queue until it is confirmed delivered. If the connection is down for an hour, that hour of orders is waiting when it comes back, not gone.
Something tells you when it fails. Not a customer. Not a month-end reconciliation. An alarm that reaches whoever needs to know, the same day.
Rebuilding one connection with those four properties is typically a few days of work. It does not require touching the rest of your system, and it does not change anything your staff see.
Where to start
Start with counting, not fixing. Take one connection and reconcile both sides for the last month. How many items should have crossed, how many actually did. That number tells you whether this is a nuisance or a serious leak, and it tells you which connection to fix first.
In parallel, it is worth knowing what shape the rest of the system is in, because brittle connections often sit on top of an old codebase where nothing else has been maintained either. The cheapest version of that question goes to your host: which versions are we on, and when does support for them end.
The larger version of this problem
Sometimes the connections are fine and the thing underneath them is the problem. If your system is on a version of its language that stopped receiving fixes years ago, many modern services will progressively refuse to talk to it — their security requirements move forward and old systems cannot meet them. This shows up as connections that used to work mysteriously failing, one provider at a time, and no amount of fixing the connection helps.
That is diagnosable quickly. If it is what you have, the fix is the underlying upgrade, and the connections stop being a problem as a side effect.
What it costs
A full audit is $2,400 fixed and five business days. For a business with integration trouble, it includes reconstructing what each connection is supposed to do, what it actually does, and where items are being lost. You get a written report you own, in plain language.
If you already know which connection is broken and just want that one made reliable, that is smaller work and can be quoted directly. The price list is here — including the parts that cost nothing.