On this page 11 sections
The pattern: a field is renamed upstream, your sync starts writing empty values, every run reports success, and the gap is found eleven weeks later by someone doing something unrelated. Nobody was negligent - each person saw a fragment that looked explicable on its own. The three checks that would have caught it on day one cost about an hour and are absent from most integrations.
This is a composite of a recurring pattern rather than a single incident. The timeline below is archetypal, and the point is how ordinary each step is.
Key takeaways
- Every individual observation had a plausible innocent explanation. That is why it survives.
- The sync did not error. It succeeded, doing nothing useful.
- The people who could see the symptom and the people who could see the cause never spoke.
- Detection cost is an hour. Reconstruction cost was weeks.
- The dead-man’s switch is the check that catches this class, and it is the one most often missing.
Who this applies to
You run integrations between systems - CRM to warehouse, store to accounting, forms to database - that nobody watches daily.
The timeline
Week 0, Tuesday. A CRM administrator renames a custom field from Lead Source to Lead Source Detail, as part of a tidy-up. It is a reasonable change, announced in a channel the data team is not in.
Week 0, Wednesday. The nightly sync runs. It maps Lead Source, gets nothing, and writes an empty string. The destination accepts empty strings. The run reports success: 1,847 records processed.
Nothing errored. Every component behaved correctly given its input.
Week 2. A marketing analyst notices attribution looks odd - more “unknown” source than usual. It is the end of a campaign period, volumes are unusual anyway, and the working theory is a tracking change. Plausible, and it is filed.
Week 5. A dashboard showing source breakdown looks flat. The person who built it left in month three. Nobody owns it. It is assumed to be a dashboard problem.
Week 7. A sales manager asks why a report shows no leads from partner referrals. Someone checks the CRM directly, sees the data is there, and concludes the report is wrong. A ticket is raised against the reporting tool.
Week 9. The reporting ticket is investigated. The report is correct - the warehouse genuinely has no partner referral data. The ticket is reassigned to the data team.
Week 11. The data team traces the pipeline and finds the sync writing empty values. Eleven weeks of attribution data is unrecoverable at source, because the CRM does not retain historical field values, so the gap can only be partially reconstructed from other systems.
Why nobody caught it
Each observation had a reasonable innocent explanation available at the time. That is what makes this pattern durable rather than a story about carelessness.
The monitoring was watching the wrong thing. Uptime, error rate and run duration were all normal, because the job ran successfully. Standard monitoring detects failure, and this was not failure - it was success at doing nothing. See why automations fail silently for the taxonomy.
The observations were spread across four teams. Marketing saw odd attribution. Sales saw a wrong report. Data owned the pipeline. The CRM admin made the change. No two of them were in the same conversation, and each fragment was individually explicable.
The dashboard had no owner. The person best placed to notice had left, and the artefact outlived the accountability.
The change was announced somewhere. In a CRM administration channel, to an audience that had no reason to know a pipeline depended on that field name.
What would have caught it
Three checks. Roughly an hour of work between them.
A volume assertion. After the sync, verify the count of records with a populated lead_source against recent runs. A sync that normally populates 1,800 and populates zero should throw. This alone catches the failure on the first night.
A shape assertion. After mapping, check that the fields you depend on have values, not merely that they exist. If every record in the batch has an empty lead_source, fail loudly with the first record attached.
A freshness check. A dead-man’s switch - the sync writes a timestamp on success, and something independent alerts if that timestamp is stale. This one does not catch this particular failure, because the job ran. It catches the sibling case where the job stops running entirely, and it is the check most often missing.
The first two would have turned an eleven-week data gap into a Wednesday morning alert.
The organisational fix
Technical checks catch the symptom. Two changes reduce how often it happens.
Register the dependency. Whoever administers the source system should be able to find out that something downstream depends on a given field before they rename it. A short document listing which fields each pipeline consumes, kept where the admin looks, is enough. It is not glamorous and it is the only thing that gets the warning to the right person before the change.
Give every dashboard and pipeline a named owner, and reassign on departure. The unowned artefact is a recurring theme in these timelines - it is where the signal appears and where nobody is responsible for reading it.
Neither is expensive. Both are the sort of thing that gets deferred because no incident has happened yet.
The wider version
The same shape appears with a filter that stops matching, an API returning an empty page with a 200, an expired token redirecting to a login page that parses as HTML, and an enrichment step whose provider silently changed a response field.
The common structure: a component behaves correctly given its input, the input changed, and the aggregate output is wrong with no error anywhere. Type checking does not help, because the values are valid - they are just empty or wrong.
That is why the defence has to assert on the shape of the output rather than on the absence of errors. It is the only layer that can distinguish “nothing to do today” from “I can no longer see anything”.
What we build in
Volume and shape assertions on every scheduled integration, a freshness check on anything whose output is not read daily, and a dependency note recording which upstream fields the pipeline consumes.
The assertion clients query most is the volume floor, because it will occasionally fire on a genuinely quiet day and somebody has to look. That is the trade and it is a good one: a false alarm costs five minutes, and this pattern costs a quarter of unrecoverable data.
The check we have to argue hardest for is the freshness one, because it lives outside the workflow and therefore outside the ticket that builds the workflow. It is also the only thing that catches a trigger which stopped firing, where there is no failed run to find because there are no runs at all.
Where the honest limit of our own work sits: we can instrument the pipeline, and we cannot make a CRM administrator in another department know that a rename will break something. The dependency register is the closest available mechanism and it depends on someone maintaining it. We recommend it, we write the first version, and whether it stays current is not something the engineering can guarantee.
When this does not apply
Pipelines whose output is read daily by a person who would notice immediately.
Short-lived integrations under active attention.
Syncs where zero is genuinely common, in which case a volume floor is noise - use shape assertions and freshness instead.
Frequently asked questions
Would better error handling have caught this?
No. There was no error. Error handling addresses a different failure class entirely - see n8n error handling for that one.
Should we alert on every empty field?
No, that produces noise. Alert when every record in a batch has an empty field you depend on, which is a structural signal rather than a data quality one.
How do we set the volume threshold?
Start at roughly half the typical minimum from recent history, then move to a rolling comparison once you have a few weeks. Existence matters more than precision.
Can we recover data from a gap like this?
Sometimes partially, from other systems or from logs. Frequently not, where the source overwrites rather than versions. That irrecoverability is the reason detection speed matters so much here.
What is the cheapest thing to add today?
The freshness check on your least-watched scheduled job. Under an hour, and it covers the largest blind spot in most setups.
Next step
If you have integrations nobody has verified recently, checking whether they are still doing work is smaller than it sounds. The maintenance and support engagement covers monitoring, assertions and scheduled verification for exactly this pattern.
Related: Why automations fail silently · n8n error handling · Scheduled or event-driven · Maintenance and support