Silent failures: how to tell that an automation has stopped

You notice only through what you have set up beforehand: an error alert, a sign of life and a count check. That includes having it in writing who checks each of them. A workflow is a chain of steps that a program carries out by itself after a trigger, for example when a form enquiry arrives. It reports a problem only if someone has set up an alert beforehand and the alert reaches a person who reads it. All vendor statements are as of November 2026.

Three ways a workflow fails silently

Kind	What happened	What reports itself
Reported error	A step fails, for example because a login has expired	An alert, if one is set up
Success without a result	The error was caught, or the step found nothing, and the run still counts as successful	Usually nothing
Never started	The trigger did not fire, or the workflow was switched off	Usually nothing, because no run fails

What the tools report by themselves differs from vendor to vendor. The statements below come from their documentation, and the wording is quoted from the original.

What counts as an error and what as a success

With n8n, a widely used tool for such workflows, you choose an error workflow in the settings of each individual workflow. It “runs if an execution fails” and must begin with the “Error Trigger” node. You can use it for several workflows and have it send an email, for instance. The error workflow cannot be triggered while you are testing: “The Error Trigger only runs when an automatic workflow errors.” And if the trigger itself fails, the alert lacks the execution number and the link. The “Stop And Error” node lets you make a run fail on purpose. That could turn an empty result into a reported error. This use is the author’s idea, not a vendor statement.

For individual nodes there is an “On Error” setting with the choice “Continue”: “Proceeds to the next node despite the error, using the last valid data.” The documentation does not say how n8n counts such a run. A forum post of 1 August 2026 (an individual report, not confirmed by n8n) says that such runs appear as successful and that the error is only in the execution data.

Make describes it explicitly. The “Skip” error handler “marks the run as successful, even if an error occurs”, “Resume” ends with the status “Success”, “Retry” with “Warning”. Without handling, the run ends with an error. After three failed runs in a row by default, Make switches the workflow off and sends an email about it.

In Zapier a run counts as “Successful” only if all steps were successful. A caught error is called “Handled error”. Zapier then does not switch the Zap off automatically, and according to its help page it sends no error emails while an error handler runs. But if 95 percent of runs end in an error within seven days, Zapier turns the Zap off.

Whoever catches errors has to build the alert themselves.

Retrying helps but can book twice

In n8n the node settings contain “Retry On Fail”: “When an execution fails, the node reruns until it succeeds.” The page on the HTTP Request node adds “Max Tries” and “Wait Between Tries (ms)”, so the number of attempts and the pause can be set. When you retry manually from the executions list, the failed node processes all items again according to the documentation, including those it had already handled before the error: “a node that sent some messages before it failed sends those messages again.” Check in the target application first what has already arrived. A successful execution cannot be retried, even if it achieved nothing. And you can retry only while n8n still stores the execution. For self-hosted n8n the default setting deletes it after 336 hours, which is 14 days. Anyone who looks only monthly will find no errors left.

Make repeats three kinds of error by itself: rate limits, connection errors and timeouts. The prerequisite is that storing incomplete executions is switched on, and it is not: “Incomplete executions are disabled by default.” When it is on, Make schedules eight attempts, the first after one minute and the last after 7 hours and 51 minutes. All other errors Make repeats only through the “Retry” error handler, which needs the same storage and, with automatic completion switched on, makes 3 attempts with a 15-minute pause by default according to the documentation.

Whether a step may be repeated is a question for your own line of work: may the same confirmation go to a customer twice? The answer belongs on the sheet.

Sign of life and count check

A sign of life is a signal that a workflow has run within the expected time. If it fails to appear, someone raises the alarm.

The n8n health check sees only the server. “/healthz” returns 200 if the instance is reachable and “doesn’t indicate DB status”. “/healthz/readiness” also checks the database. Neither says whether an individual workflow is running.

That a workflow is “published” and still does not run is, with n8n, even a described state. With “Published, partial” at least one trigger did not start, and “n8n doesn’t unpublish it”. With “Failed to publish” the documentation says: “None of the workflow’s triggers activated, so the workflow isn’t running.” If neither the workflow nor the instance has a timezone set, n8n uses New York (EDT) according to the documentation, and a schedule then runs several hours off German time.

A forum post of 1 August 2026 (an individual report) suggests a watchdog workflow on a schedule. Through n8n’s public interface it retrieves the time of the last execution for each workflow and compares it with the expected window. It also checks whether the workflow is still listed as active. A second post, of 2 August, adds that a workflow that was never activated has no execution at all in which a gap could show. According to the documentation the interface is available for self-hosting in all editions, in the cloud from the Starter plan. This is not a measured solution.

Simpler and without technology is the count check, a suggestion by the author: you compare a number at the start with a number at the end. For an enquiry form, that is the arrivals in the mailbox against the entries in the enquiry list. If the numbers differ, something has failed silently, even if every execution was reported as “successful”.

Example with invented data

A business gets 30 appointment enquiries a month through a form, so one a day (30 divided by 30). A login expires and the workflow stops creating entries.

The figures in the graphic are assumptions. Without monitoring, the failure shows after 5 days for the reported error, after 14 days for the workflow that never started, and only after 30 days for the success without a result. With monitoring it is 1, 1 and 7 days: alert on the same day, daily sign of life, weekly count check.

no monitoringwith monitoring

• Reported errorAssumption, alert on the same day

  no monitoring 5 days
  with monitoring 1 days

• Workflow never startedAssumption, daily sign of life

  no monitoring 14 days
  with monitoring 1 days

• Success without a resultAssumption, weekly count check

  no monitoring 30 days
  with monitoring 7 days

Source: Example with invented data, the author’s assumptions, not measured

Text version of the graphic

• Reported error: no monitoring 5 days, with monitoring 1 days (Assumption, alert on the same day)
• Workflow never started: no monitoring 14 days, with monitoring 1 days (Assumption, daily sign of life)
• Success without a result: no monitoring 30 days, with monitoring 7 days (Assumption, weekly count check)
• Source: Example with invented data, the author’s assumptions, not measured

At one enquiry a day, 7 days until discovery means up to 7 unanswered enquiries. A daily count check cuts that to 1 day. If we assume 2 minutes per check, it costs 5 times 2 minutes, so 10 minutes per working week.

Who reads the alert

According to its help page, Zapier sends error alerts by default to the email address of the Zapier account. Who created that account? If it is a former employee or a service provider, the alert goes nowhere. With n8n, your own error workflow decides the recipient. I did not check how Make sets the recipient. A group address of the office with a named deputy is sturdier than the email of one person. That is the author’s recommendation and not a vendor requirement.

Error texts can contain customer data. According to its documentation, n8n offers redaction of execution data; I did not check its availability by plan. Better to send only the workflow name and a link in the alert. Which data may go into which tool is covered in Data zones. What is permissible for your data is for your data protection officer to clarify.

The sheet for each workflow, one page, should hold:

• Name, purpose and expected frequency, for example “30 enquiries a month”
• Recipient of the error alert, deputy and time allowed to react
• Retry yes or no, with the risk of duplicate emails or bookings
• Count check: which number against which, who checks, how often
• Where the logs are kept and for how long
• Who manages the logins and when they expire

What you can do now

1. Write the sheet for every running workflow, even a small one.
2. Ask whether an error alert is set up for each workflow and where it goes. Test it with an automatically running test workflow that fails on purpose.
3. Set a count check (how to measure times before and after introduction is covered in Measure time savings) and put the first one in the calendar for two weeks from now.
4. Ask your service provider where errors are caught and who is informed then.