Workflow
What actually happens when an automation breaks
We took a working workflow and broke it deliberately in several different ways to document what each failure looks like from the outside — and in particular whether anything tells you.
No link on this page is an affiliate link. We are in the programme below, so we could earn a commission elsewhere on this site — but not from anything on this page. We recommend free tools where they are the better answer, including ones that earn us nothing.
- Make.com: 35% of subscription payments for 12 months; extra-operation purchases do not earn commission (terms verified 2026-09-24)
The problem this addresses: My automation broke and I did not find out until someone complained.
The steps
- Start from a workflow that is known to work. Verified by successful runs first.
- Induce an upstream failure. Downstream endpoint returns HTTP 500 at a controlled rate.
- Induce a malformed payload. Required fields missing entirely.
- Record what happened. Did it retry? Did it notify? Was data lost? Was the failure visible at all?
What we measured
What this measurement is, and what it is not
These numbers come from running this workflow’s logic against a local test stack over real HTTP, using synthetic data. They describe the workflow design — how many units of work it costs and how it behaves when things go wrong. They are not measurements of Make, n8n or Pabbly, and nothing here should be read as a claim about any vendor’s product.
| Condition | Attempts | Lost | Extra units consumed |
|---|---|---|---|
| 50% failure rate, no retry | 20 | 6 | 0 |
| 50% failure rate, up to 3 retries | 20 | 4 | 14 |
| Total outage | 5 | 5 | 0 |
Retries are billable. Recovering those runs consumed 14 extra units of work. On a platform that bills per step, you pay for every retry.
The workflow failed and told nobody
We placed the notification step after the step that fails. When the workflow aborted, the notification never ran. Notifications delivered: 0. This is why an error notification has to live in a separate workflow.
Missing merge fields reach the customer
A template with unfilled fields was sent with the placeholders intact — FirstName</code>, <code>StartDate — and no error was raised. The recipient would have received: “Hi {{FirstName}}, your start date is {{StartDate}}.”
Platform status
n8n (self-hosted Community) — Community (self-hosted)
- Not tested. n8n Community could not be installed on this machine: the npm install exhausted available disk space and failed. See 15_qa_report.md for the exact figures. Workflow JSON has been authored and is ready to import, but IT HAS NOT BEEN RUN, so no n8n result is claimed.
- We do not describe untested workflows as working. This section will be updated once the test is possible.
Make.com — Free
- Not tested. Requires an account, which the agent is not permitted to create. Owner action needed before this platform can be tested.
- We do not describe untested workflows as working. This section will be updated once the test is possible.
Pabbly — Free
- Not tested. Requires an account, which the agent is not permitted to create. Owner action needed before this platform can be tested.
- We do not describe untested workflows as working. This section will be updated once the test is possible.
Limitations and failure cases
- Retry behaviour is configured per node or per scenario. It is almost never on by default, which is precisely why failures go unnoticed.
- A workflow that fails before its notification step cannot notify you that it failed. This needs a separate error workflow, not a step inside the same one.
Failure cases we induced deliberately
- Intermittent 500s from a downstream service — tested at a controlled failure rate.
- Malformed input with required fields missing — tested.
- Total downstream outage — tested at a 100% failure rate.
Access and permissions this needs
- None beyond the workflow being tested.
Security and privacy
- Failure logs frequently contain the full payload, including personal data. If you send failure notifications to a team chat, you may be copying customer details into it.
Free options, and when you would have to pay
- Error-handling features differ by tier on hosted platforms. Self-hosted n8n Community has them without charge.
What pushes you onto a paid plan: Nothing here requires a paid tier, which is worth saying plainly.
The limits of this test
What we can say
- We can state exactly what each induced failure produced, because we induced them and kept the logs.
- We can state whether a failure was silent, because we looked.
What we cannot say
- We cannot describe Make's or Pabbly's error handling until we have run these same tests on them.
- We cannot claim how often this happens in production. We have no production.