A workflow can stop doing useful work without producing a dramatic error. Its trigger might be disabled, a source might stop sending events, or every run might finish while putting records in the wrong place.
Monitor both execution and the business result. You need to know that the workflow is running, that expected work is arriving and that it reaches the intended outcome.
Separate three kinds of failure
A run fails: a connection is rejected or an action can't complete. This is the failure most automation platforms make visible.
No run starts: there are no incoming events, a schedule has changed or a trigger is disabled. An error alert for failed runs may have nothing to report.
A run succeeds with the wrong result: a task goes to the wrong team or an incomplete record is marked ready. The platform may correctly report that it carried out its instructions.
Give each kind of failure a check. Otherwise a reassuring green history can hide the problem the business actually cares about.
Start with a short operating record
For every important automation, write down its owner, expected input, expected output and normal operating pattern. Add the place staff can see pending work, the alert route and how to pause it safely.
For a fictional repair company, the record might say: valid website jobs should reach the allocation list within the agreed working interval. The daily check compares accepted requests with allocated or explicitly rejected requests. It doesn't merely count how many runs completed.
Use the original request reference to investigate a missing item. Avoid alerts containing full customer messages or credentials when a reference and restricted link would be enough.
Use platform errors, but understand their limits
n8n allows an error workflow to respond to failed executions, including sending an alert. It needs to be configured for the workflow. That is useful for execution failures, not proof that every expected event arrived.
Zapier's run history provides run statuses and details for investigating what happened. Check what history your plan retains and who can access it. An old error isn't helpful evidence if nobody can retrieve the relevant run when the customer calls.
For either platform, test the alert deliberately in an environment you control. Confirm that the responsible person receives something they can act on, with a reference and a clear next step.
Check for missing work and wrong results
Choose checks suited to the process:
- compare incoming requests with completed, waiting and deliberately rejected items.
- flag items older than the agreed working interval.
- check that a scheduled report has arrived for the expected period.
- sample destination records for correct values and ownership.
- investigate a sudden absence of activity against the expected pattern.
An activity threshold must respect the business. A shop closed on Sunday doesn't necessarily have a fault because Sunday's count is zero. A workflow handling sensitive records may need fictional test records in a separate environment rather than production “heartbeat” submissions.
Make an alert lead to a decision
Name the first responder and a deputy. State when the issue needs immediate attention and when it can wait for working hours. Several alerts saying “automation failed” won't tell a receptionist whether customers have received duplicate messages.
The recovery notes should answer: what may already have happened, which records are affected, what can be paused and who can authorise a replay. Restoring a connection doesn't establish that replaying an entire run is safe.
Before retrying work that sends messages, creates orders or changes records, inspect the completed steps. You may need to resume one item or correct an output rather than start everything again.
Include the monitoring in handover
Ask the builder to demonstrate a failed connection, a missing input and an incorrect destination in a test setup. Show staff where each problem appears and what they should do next.
Review the checks after a process or subscription changes. A monitoring rule that still expects yesterday's schedule can generate noise or miss the current problem.
An automation is ready for routine use when the business can discover and handle a failure as well as watch a successful demonstration. Keep that operating work in the scope and budget from the start.