Integrations Fail Silently

Alexander Chua
7 min
Integrations Fail Silently

The short version

  • Integrations built on form IDs break whenever the form is rebuilt, and they break quietly.
  • Error alerting does not catch this, because nothing errors. The pipe is fine and empty.
  • Alert on absence, not on failure: if volume is zero for longer than normal, something is wrong.
  • Write down what each integration depends on. The dependency is usually an ID somebody will change without knowing.

A lead sync we inherited had been broken for weeks. Ads to a spreadsheet to a notification channel to the email tool, and it worked perfectly until somebody swapped the ad form. Nothing errored. Nothing alerted. Leads simply stopped arriving, and the first signal was a salesperson asking why it had gone quiet.

Why do integrations fail without erroring?

Because most integrations are triggered rather than polled. A form submits, a webhook fires, a row appears, the chain runs. Change the form and the trigger points at something that no longer exists, so the chain is never invoked.

Nothing throws an exception. There is no failed run to appear in a log, because there was no run. From the monitoring tool’s point of view the integration is healthy and idle.

What breaks, and whether anything tells you:

ChangeMade byErrors?How it surfaces without monitoring
Form rebuilt, new IDMarketingNoSales notices the silence, weeks later
Field renamedAnyoneSometimesRecords arrive with blank fields
Tool migratedITNoWebhook posts into nothing
API key rotatedIT or securityYesFailed runs in a log nobody reads
Send quota hitVolume growthSometimesPartial delivery, silent truncation

What actually breaks these chains?

An ID changing underneath. A form rebuilt rather than edited, so it gets a new identifier. A field renamed, so the mapping no longer matches. A tool migrated, so the webhook URL is stale. An API key rotated on a schedule nobody told you about.

All four are routine maintenance by somebody who has no idea an integration depends on them.

How do you monitor for silence?

Set a floor and alert when volume falls under it for longer than the normal quiet period. If the form usually produces leads every weekday, then two consecutive weekdays at zero should page somebody.

This is the only check that catches the failure mode, because the failure looks exactly like a slow week until it does not.

Alert on absence, not on failure. A broken pipe and a quiet week look identical until you have a baseline.

How often should you test one?

After any change to a form, field, tool or key, and on a schedule regardless.

A monthly synthetic submission that runs the whole chain end to end and confirms arrival at the destination is the only test that proves the pipe works during a genuinely quiet period. Without it you cannot distinguish a broken integration from a slow month, which is the exact ambiguity that let this one run broken for weeks.

What should you document?

For each integration: what triggers it, which specific IDs or field names it depends on, where the data lands, who owns each end, and what normal volume looks like.

That last item is what makes an alert possible. Without a baseline, nobody can tell the difference between a broken pipe and a quiet Tuesday.

The neighbouring failures worth auditing at the same time are checking the ceiling of every tool in the chain and verifying what is actually live.

Frequently asked questions

Why do marketing integrations break without any error?

Because most are trigger-based rather than polled. If the trigger identifier changes, such as a form being rebuilt with a new ID, the chain is never invoked. There is no failed run to log, so monitoring reports the integration as healthy and idle.

What is the most common cause of a broken lead sync?

A form being rebuilt rather than edited, which assigns it a new identifier. The integration still points at the old one. This is routine maintenance by someone who has no idea anything depends on that ID.

How do you monitor an integration that fails silently?

Alert on absence. Establish what normal volume looks like, set a floor, and page someone when volume stays under it longer than a normal quiet period. Error alerting cannot catch a chain that never runs.

What should be documented for every integration?

The trigger, the specific IDs and field names it depends on, where data lands, who owns each end, and what normal volume looks like. The last one is what makes alerting possible at all.

How often should integrations be tested?

Test end to end after any change to a form, field, tool or key, and run a scheduled synthetic submission at least monthly. A synthetic test is the only way to prove the chain still works during a genuinely quiet period.

Who should own an integration between two teams' tools?

One named person, usually whoever owns the destination, because they are the one who notices missing data. Shared ownership produces the situation where both ends assume the other is watching.

Sources

  • Chua Network delivery data across 8 client accounts (internal fact bank)
  • Chua Network engagement records, anonymized (internal experience bank)
Alexander Chua

Alexander Chua

Co-Founder, PipelineRoad. Building companies and observing the world across 40+ countries. Writing about company building, go-to-market, capital formation, and the lessons in between.

More about Alexander

Newsletter

Chua Network Letter

Occasional essays on company building, global observations, and clear thinking. No spam. No SEO bait.