A workflow that works perfectly in testing will eventually hit a flaky API, a rate limit, or a malformed record from upstream. The difference between an automation you trust and one that quietly breaks for two weeks before anyone notices is entirely about what you do before that happens, not after.
What happens by default
Out of the box, if any node in a workflow throws an error, the entire execution stops at that point and is marked as failed. Nothing downstream runs. If nobody's watching the Executions list, that failure can sit invisible indefinitely - which is exactly the scenario every automation eventually needs to guard against.
Retry on Fail
Most nodes have a "Retry On Fail" option in their settings panel, with a configurable number of attempts and a wait time between them. This alone solves the most common real-world failure: a transient network blip or a momentary API rate limit that would succeed on the second try. Turn it on for any node calling an external API, especially ones you don't control.
Continue On Fail vs stopping the workflow
Some failures shouldn't halt everything. A node's "On Error" setting (in newer versions, found under the node's settings) can be set to "Continue," which lets the workflow keep going even if that specific node failed - useful when processing a batch of items where one bad record shouldn't block the other 49. Use this deliberately, though: silently swallowing every error is how workflows fail quietly instead of loudly.
Error workflows: the real safety net
In workflow Settings, you can assign a separate Error Workflow that automatically runs whenever this workflow fails - typically something simple like "send a Slack message" or "log to a spreadsheet" with the error details included. This is the single highest-leverage thing to set up once you have more than a couple of production workflows: you find out about failures within minutes instead of when a customer complains.
Building a reusable error notifier
Rather than building a new error workflow for every automation, build one generic "notify on error" workflow that accepts the failing workflow's name and error message as input, and assign it as the Error Workflow across all your important automations. One place to update the notification logic, consistent alerts everywhere.
Debugging a failed execution
Click into any failed execution from the Executions list and n8n shows you exactly which node failed and the error message it threw, along with the full input/output data at every step leading up to it - the same data-flow visibility covered in the canvas guide, now applied to diagnosing a real failure instead of building a new workflow.