Your integration silently failed — how to catch it sooner

The most dangerous integration is not the broken one but the silent one. How integrations stop unnoticed, and the four questions that prevent it.

The integration between your webshop and your accounting has been running for two years. Then the accountant calls: six weeks of orders are missing. The integration raised no error and nobody saw anything. It had simply stopped, quietly, somewhere on a Tuesday night.

We hear versions of this story again and again, and the dangerous part is precisely the silence. An integration that breaks with an alarm is an uncomfortable day. An integration that stops without a word is six weeks of bookkeeping to reconstruct.

Why integrations stop silently

Rarely because of one big outage. Nearly always because of something small on either side. The connected package got an update and a field changed names. A password or API key expired. The vendor introduced a new rate limit. One odd message, a customer with a second billing address, got stuck and everything behind it waited along.

The integration itself is fine with all of this. It tries something, it fails, and unless someone taught it what should happen next, nothing happens. No message is the default state of most systems, and that is the problem: silence and success look identical from the outside.

Slow systems make it more treacherous

There is an extra trap many companies discover late: not every system answers immediately. Some parties process requests in batches and answer after hours or days. An integration not built for that does something worse than break: it concludes “no answer, I must be done” and moves on. The message is gone, and nothing ever beeped.

A good integration can wait. It remembers what is outstanding, loses nothing while the answer is on its way, and picks the thread back up when it arrives, even if that takes three days. Only when the answer stays out too long does it raise its hand. The difference between “slow” and “broken” has to be built into the integration; otherwise every slow party becomes a silent gamble.

How to catch it sooner

Good news: this is a solved problem. It needs no big project, only the requirement that your integration can do three things.

Report that it failed. Not into a log file nobody reads, but as a message to someone who can act. The integration that jammed at 03:12 belongs in somebody’s morning at 08:00.

Report that it is quiet. The cunning failure raises no error, so next to “it failed” you need “it is suspiciously quiet”: if your integration normally processes dozens of orders a day and today zero, that deserves a message even though no error occurred anywhere. In our own workflow platform that has been a lesson from practice: the alerts on unusual silence catch problems no error message would ever have reported.

Be able to tell what happened. Every run leaves a record: what was processed, what is waiting, what failed and why. When the accountant asks about six weeks of orders, you look it up instead of reconstructing it.

The four questions for your builder

If you have an integration, or are commissioning one, put these four questions to the vendor. The answers tell you everything:

1. How do we find out when the integration stops, and how fast?
2. What happens to a message that cannot be processed?
3. What does the integration do with a system that answers only after hours or days?
4. Where can I read back what was processed last night?

Four clear answers: good, then this piece was reassurance. Hesitation at question one: then you now know what belongs on your wish list, before the accountant calls.

Unsure about your own integrations? We will take a sober look; how we build them is on system integration, and asking a question takes two minutes via contact.