You wired two systems together. It worked for four months. Then one Tuesday, quietly, it stopped, and nobody noticed for two weeks.
This is the normal life cycle of a small business integration, and it is avoidable.
The five ways integrations die
1. Something changed upstream. A vendor updated their API, renamed a field, changed a permission, or deprecated a version. Your side is unchanged and now broken.
2. Credentials expired. A token with a lifetime nobody tracked. An account whose password was changed. A user who left the company and whose login the integration was quietly using.
3. Bad data hit an assumption. The integration expected a phone number and got a note. Expected a date and got "ASAP." Expected a value and got nothing. It either errors or, worse, writes something wrong.
4. Volume outgrew it. Fine at thirty records a day, rate-limited at three hundred.
5. A human changed something. Somebody renamed a column, edited a form field, restructured a folder. The integration was pointing at the old name.
Notice that only one of those is a coding problem. The rest are environment problems, which is why "it worked when we built it" is not a defence.
The problem is not the breaking, it is the silence
An integration that fails loudly is an inconvenience. One that fails silently is a data problem that compounds every day until someone notices.
Two weeks of leads that never reached the CRM. A month of invoices that never got created. A follow-up sequence that stopped enrolling people.
By the time it surfaces, you have both a broken system and a backlog nobody can reconstruct.
Build for failure
Alert on failure. Anything automated should tell someone when it fails. Not a log nobody reads — a message to a person.
Alert on silence, too. This is the one people miss. If a process normally runs fifty times a day and today it ran zero, that is a failure even though nothing errored. Monitor for absence, not just for errors.
Retry, then escalate. Transient failures are common. Retry a few times with a delay, and if it still fails, tell a human.
Never lose the input. If step two fails, the data from step one should still exist somewhere. The worst version of a broken integration is one where the original information is gone.
Validate before you write. Check the data is what you expect before it goes into the destination system. Wrong data in a CRM is harder to fix than no data.
Fail safe, not silent. If the system cannot do the right thing, it should stop and flag rather than guess.
Reduce how much you have connected
Every connection is a thing that can break. Owners accumulate integrations because each individually seems useful, and then have eleven fragile links.
Worth asking of each one: what actually depends on this? If it stopped, who would care and when?
The ones nobody would notice should be deleted. Every removed integration is one fewer thing to maintain, and there is real value in that.
Prefer boring connections
- Native integrations from the vendors themselves are usually more stable than something you assembled, because the vendor maintains them.
- Fewer hops. A chain of four tools has four failure points and diagnosing it means checking all four.
- Documented, versioned APIs over scraping or undocumented endpoints, which change without warning.
- Webhooks over polling, where available — fewer moving parts and less to rate-limit.
Write down what you built
The single most common thing I find in small businesses is an automation nobody can explain. It was set up by someone who has left, in a tool nobody logs into, doing something important.
For each automation, record: what it does, what triggers it, what it connects, whose account owns it, and who to tell if it breaks. One page.
That page is what turns a mystery into a maintainable system.
Check them on a schedule
Once a quarter, verify each one is actually running. Not that it exists — that it ran, recently, and produced the right result.
It takes an hour and it is the difference between finding a break in three days and finding it in three months.