Every automation works when you build it. You have clean test data, one record at a time, and you are watching. Production has none of those things. Here is what actually takes them down, in rough order of how often it happens.
1. Rate limits
You tested with three records. The first real run has nine hundred, and the API starts returning 429 halfway through. Now you have a job that half-succeeded, and no idea which half.
The fix: retry with exponential backoff, respect the Retry-After header when the provider sends one, and batch where the API supports it. Both n8n and Make have retry settings on individual steps — the mistake is leaving them at the default because the demo never needed them.
2. Partial failure
Step four of six fails. Steps one to three already happened. If those steps wrote data somewhere, you are now in a state your flowchart does not describe: an invoice with no line items, a customer with no welcome email.
The fix: make each write idempotent, and do the irreversible things last. If you can order a workflow so the risky external call happens before anything is committed, do that. Where you cannot, record enough to resume: an execution id, a cursor, what has already been done.
3. Duplicate triggers
Webhooks are delivered at least once, not exactly once. Providers retry when they do not get a fast 200, and "fast" is often two seconds — shorter than your workflow takes. So the same event arrives twice and you create two records.
The fix: take the provider's event id, store it, and drop anything you have already seen. A single unique index on that column solves this permanently and costs nothing. Then answer the webhook immediately and do the work afterwards, so the retry never fires in the first place.
4. Schema drift
A field you rely on gets renamed. A number starts arriving as a string. A provider adds a required parameter with a month's notice you did not read. Your mapping silently produces nulls, and the workflow keeps reporting success while writing rubbish.
The fix: validate the shape of what you receive before acting on it, and fail loudly when it is wrong. A workflow that stops is annoying. A workflow that carries on writing empty fields into your CRM for three weeks is expensive.
5. Silent death
The worst one. The workflow was disabled by an expired credential, or the trigger stopped firing, or the container was restarted and never came back. Nothing errors, because nothing runs. You find out when somebody asks why they stopped getting the report.
The fix: alert on failure and on absence. A daily job that checks "did the important workflow run today?" catches the entire class of problems that error handling cannot, because there is no error to handle.
What to build every time
Five things, none of which take long once they are habit:
- Retries with backoff on every external call.
- An idempotency key on every write.
- Validation of incoming data before it is used.
- An error branch that reaches a human, with enough context to act on.
- A heartbeat check that notices silence.
None of it is glamorous, and all of it is the difference between an automation you demo and one you can leave running while you are on holiday.
Every course here builds these in from the first version rather than bolting them on at the end. Browse the catalogue.