Why this matters
Maple Lane Florist has a workflow that runs every morning at 6, gets the day’s wholesale prices from its flower supplier and updates the price sheet. One morning the supplier’s server was busy, the run failed, and nobody noticed.
For three days the shop quoted customers from old prices. The first sign was a wedding order that lost money. A silent failure costs real money.
In this module you make sure that never happens quietly again. You build an alert, make a flaky step try again by itself, and use the run log to redo a failed run.
What you’ll build
An error workflow called Error alerts: an Error Trigger followed by a Gmail email that names the workflow, the step that broke, the error message and a link to the failed run.
In the supplier workflow, the HTTP Request step retries three times, five seconds apart, and sends a failure down an Error output to a second email, so the run still finishes. Then you retry this morning’s failed run from Executions.
What you need
- Nothing to start the practicen8n, Gmail and the supplier are practice copies. Maple Lane Florist and its supplier are made up.
- An n8n account, to do it for realSign up with this link (affiliate link: I may earn a commission, at no cost to you).
- A Gmail connectionIn the Send a message step, create the Gmail credential and choose Sign in with Google. Use an address you actually read in the To field.
- A workflow that can failAny workflow with a step that calls an outside service, like an HTTP Request, which can fail when that service is busy. In the lesson, this is Supplier price check.
Concepts
3 ideas you’ll use in the practice.
An error workflow tells you when another one fails
Create a separate workflow that starts with an Error Trigger. It has nothing to set up. It hands the next step the failed workflow’s name, the step that broke, the error message and a link to the run.
Add Gmail Send a message with your own address, the subject A workflow failed, and those details in the message.
Retry On Fail covers a busy server
Open the step, go to the Settings tab and turn on Retry On Fail. Max. Tries is 3. Raise Wait Between Tries to 5000, which is five seconds and the most the field allows.
Only retry steps that are safe to repeat. Never turn it on for a step that charges a card.
On Error decides what happens after the last try
The default, Stop Workflow, ends the run. Choose Continue (using error output) instead. The step gets a second output called Error. Connect it to an email that says what the failure means, such as "Supplier prices did not update".
The Executions tab is the run log. Red means error. Open the run and click the retry icon, then choose Retry with currently saved workflow, which starts again from the node with the error.
Practice
Do every step yourself in a practice copy of the real tool. It checks your work, and “Do it for me” finishes any step you get stuck on.
Do it for real
Now repeat it in your own account. Tick each step as you go.
Quick check
3 questions to check you’ve got it.
1. What starts an error workflow?
- An Error Trigger, when another workflow fails
- A schedule
- A form submission
Show the answer
An Error Trigger, when another workflow fails. The Error Trigger runs the workflow whenever a workflow that points at it errors.
2. Why should you never turn on Retry On Fail for a step that charges a card?
- It would be slower
- A retry could repeat the action and charge twice
- n8n does not allow it
Show the answer
A retry could repeat the action and charge twice. Retries repeat the step. Only use them where repeating is safe.
3. What does Continue (using error output) give you?
- A second Error output, so a failure can send an email while the run still finishes
- A faster step
- A longer wait between tries
Show the answer
A second Error output, so a failure can send an email while the run still finishes. Stop Workflow ends the run. Continue passes the error down its own path, as data.