Why Your Integrations Break and Nobody Notices

A connection between two systems stops working on a Tuesday. Nothing goes red. No alert is sent, because nobody built one.

Three weeks later somebody notices that records have stopped arriving, and now there is a backlog nobody can reconstruct and a period where the reporting was quietly wrong.

Why failures are silent by default

Most integrations are built to handle the case where everything works. That is the case that gets tested, because it is the case somebody was trying to create.

When a service changes an interface, a credential expires or a file arrives in an unexpected shape, the process simply stops. From the outside nothing looks different. There is no error on anybody’s screen because nobody was watching a screen.

The absence of something is much harder to notice than the presence of a problem, and integrations fail by absence.

The failures that recur

• Expired credentials. A token or password with a lifetime nobody recorded. Works for months, then does not.

• Interface changes. A supplier updates their system and a field is renamed. Your process was never told.

• Unexpected input. A file arrives with an extra column or a date in a different format, and the whole run stops.

• Limits. Volume grows past a threshold and requests start being refused rather than processed.

• The person who built it left. Not a technical failure, and the most common reason nothing gets fixed.

Build the failure path first

The single most useful habit is to design what happens when a step fails before designing the step.

Retry, because a good share of failures are transient. Then, if it still fails, tell a named person with the reason attached and the record it stopped on. Not an alert into a channel nobody reads. A person, with enough detail to act.

The second habit is the heartbeat. A process that should run daily and has not run should raise an alarm by absence. Without that, silent failure stays silent.

Where AI does the watching

Rules catch the failures somebody predicted. AI catches the ones nobody did.

It watches the shape of what normally happens. Roughly this many records a day, arriving at these times, with these fields populated. When the pattern changes without anything technically erroring, it raises it. A supplier that quietly started sending half the usual volume is not an outage and it is a problem.

It also handles the input variation that stops rule based processes cold. A date in a different format, a renamed column, an extra section in a document. Interpreting those was exactly what required a person, which is why the process used to stop and wait for one.

What to check this week

List every automated connection you rely on. Most businesses cannot complete this list, which is itself the finding.

For each one, ask how you would know if it stopped. If the answer is that somebody would eventually notice something missing, it is unmonitored.

Then ask who fixes it. If that person has left, you have a dependency rather than a system.

The credential problem

Of all the silent failures, expiring credentials are the most predictable and the least prepared for.

Somebody connects two systems using an access token. It works. Ninety days or a year later it expires, because that is what tokens do, and nothing was recorded about when or who would renew it.

Keep a list of every credential a system depends on, what it is for, when it expires and who owns renewing it. That list takes an hour to produce and prevents the most common outage in small business software. Almost nobody has one, which is why almost everybody has had this outage.

Testing something you cannot see

The awkward property of a working integration is that success looks like nothing happening.

Which is why the only reliable test is a synthetic one. Push a known record through the whole chain on a schedule and confirm it arrived at the other end with the right values. If it does not, you know within the hour rather than within the month.

That costs very little to build and it converts an entire class of invisible failure into an alert. It also catches the subtler problem: a connection that is technically running but silently dropping or mangling part of what it handles, which no error log will ever show you.

What to do when it does break

Two things matter and most businesses have neither.

Know what was missed. A failure between Tuesday and Friday means records exist somewhere that never arrived. If you cannot identify the window and replay it, you are reconstructing by hand from memory.

Be able to run it again. A process designed to be re run for a date range turns an outage into an inconvenience. One that cannot be, turns the same outage into a week of manual data entry and a permanent gap nobody trusts.

Ownership is the actual fix

Every technical answer here is secondary to a management one.

Somebody has to own each connection. Not the department that uses it, and not the person who happened to build it if they have left. A named individual who receives the alert and knows what to do with it.

Fifteen minutes a month across a handful of integrations is the whole governance requirement. Without it, monitoring produces alerts that nobody acts on, which is very slightly worse than no monitoring at all because it creates a false sense of coverage.

Documentation is what makes it survivable

A connection nobody can explain is a liability with an expiry date attached to one person’s employment.

The record needs four things: what this moves and between which systems, what triggers it, what it depends on, and what to check first when it stops. Half a page. It takes twenty minutes to write while building and is close to impossible to reconstruct a year later from the system alone.

AI Optimize builds the retries, the escalation and the monitoring that make a connection something you can rely on rather than something you hope is still running. That work sits under Custom AI Integrations.