Add an alert to any automation in ten minutes. Here is how
To add an alert to any automation, pick the step most likely to fail, attach an error route that catches the failure, send yourself a notification with the details, then force a fail to confirm the alert fires. This whole setup takes about ten minutes and works across most platforms.
You do not need a monitoring dashboard or a new tool. You need one error route and one notification on your most important workflow.
- An automation without an alert can fail silently for days before anyone notices the missing output.
- An error route is a branch that runs only when a step fails, and it is where your notification lives.
- You should place the alert on the single step most likely to break, not on every step at once.
- A notification only counts as useful if it tells you which automation failed and where.
- You must force a fail to prove the alert works, because an untested alert is not an alert.
- This setup takes about ten minutes and works in Make.com, GoHighLevel, Power Automate, and most builders.
Most automations run in the dark. They fire on a schedule or a trigger, do their work, and go quiet. When they succeed, you get output. When they fail, you often get nothing at all. No error. No warning. Just silence that looks exactly like success. That is the problem an alert solves, and you can add an alert to any automation in ten minutes.
An alert on an automation is a notification that fires the moment a step fails, so you learn about the break in minutes instead of discovering it days later through a missing report or an angry client. The alert lives inside an error route, which is a branch that only runs when something goes wrong. Together they turn a silent failure into a message you actually see.
The steps below are tool-agnostic. Whether you build in Make.com, GoHighLevel, or Power Automate, the logic is the same. Pick the failure point. Add an error route. Send yourself a notification. Force a fail to test it.
Step one: pick the failure point
The failure point is the single step in your automation most likely to break, usually a call to an outside service like an email sender, a payment processor, or an API that you do not control. You do not alert every step. You alert the weak link. The steps that touch the outside world fail more than the ones that just move data around inside the tool.
Walk through your workflow and ask one question at each step. If this breaks, does the whole thing stop being useful? The step where the answer is yes is your failure point. Common ones include:
- A webhook or API call to an external service
- An email or SMS send that depends on a third-party provider
- A data write to a spreadsheet, CRM, or database
- A payment or invoice action
The step most likely to fail is almost always the one that talks to a service you do not control.
Why one failure point beats ten
Alerting every step feels safe. It is not. Ten alerts on ten steps means ten messages to sort through when one thing breaks, and it trains you to ignore them. Start with one. You can always add more once the first one earns your trust.
Step two: add an error route
An error route is a separate branch in your automation that runs only when a step fails, and it is where you catch the break before it disappears into silence. Most platforms build this in. In Make.com you right-click a module and add an error handler. In Power Automate you use the “Configure run after” setting to run a step only when the prior one fails.
The pattern is the same everywhere. You wrap or tag the failure point so the tool knows what to do when it breaks, instead of just stopping. Microsoft’s official guidance on robust error handling in Power Automate walks through grouping steps into try and catch scopes so a failure routes cleanly to a recovery path.
Here is how the error route concept maps across common tools.
| Platform | How to add an error route | What it is called |
|---|---|---|
| Make.com | Right-click the module, add an error handler branch | Error handler |
| Power Automate | Set “Configure run after” to run on failure, wrap in a scope | Configure run after |
| GoHighLevel | Add a conditional branch checking the prior step result | If/else branch |
| New Relic workflows | Add a fallback action for a failed step | Fallback action |
ServiceNow’s Center of Excellence covers the same idea with a try/catch approach to flow error handling, where a failure gets captured and pushed to whoever owns the process. Different names, same shape.
Step three: send yourself a notification
A notification is the message your error route sends when a step fails, and it must tell you three things: which automation broke, which step broke, and roughly what the error was. A vague ping that says “something failed” wastes your time. A good notification lets you act without opening the tool.
Inside the error route, add a step that sends a message to a channel you actually watch. Email works. So does SMS, Slack, or a push notification. Pick the one you cannot ignore. Then fill the message with detail:
- The name of the automation, so you know what broke
- The step or module name, so you know where it broke
- The error text the platform returned, so you know why
- A timestamp, so you know when
A notification that does not name the automation and the failed step is not worth building.
New Relic’s documentation on workflow automation best practices makes the same point about fallback notification actions and checking execution history when a critical step fails.
Step four: force a fail to test it
To force a fail, you deliberately break the failure point once, then run the automation and confirm the notification arrives with the right detail, because an alert you have never tested is a guess, not a safety net. This is the step most people skip, and it is the one that matters most.
Forcing a fail is simple. Feed the step bad input on purpose. Swap in a wrong API key. Point an email send at an address that does not exist. Break the thing, run it once, and watch. Did the alert fire? Did it name the right automation and step? Did the message reach you where you actually look?
An untested alert is not an alert. It is a hope that you will find out when something breaks.
Once the notification lands correctly, undo your sabotage and restore the real input. Now you have proof. Microsoft’s training module on error handling in flows reinforces this: isolate the failure, route it, and confirm the notification path works before you trust it in production.
A ten minute checklist
- Minute 1 to 2: find the step most likely to fail
- Minute 3 to 5: add the error route to that step
- Minute 6 to 8: build the notification with automation name, step, and error text
- Minute 9 to 10: force a fail, confirm the alert, then restore
That is the whole thing. If you want help building this into more of your systems, the resources at Hot Hand Media walk through the same automation patterns in more depth.
The word “alert” comes from the Italian military phrase “all’erta,” meaning “on the watchtower.” At Hot Hand Media we think that is a perfect description of what an error route does. It is the watchtower your automation never had, standing guard so a silent failure cannot slip past you.
In my work with small teams running automations in Make.com and GoHighLevel, the pattern that shows up most is not a broken build. It is a build that broke quietly weeks ago and nobody knew. The automation was fine on the day it launched. Then a third-party service changed something, the step started failing, and the output just stopped. No alert meant no one looked. The teams that add one error route to their most important workflow catch these breaks the same day instead of hearing about them from a frustrated client. Ten minutes of setup buys you weeks of peace.
How do I add an alert to an automation?
You add an alert by picking the step most likely to fail, attaching an error route to it, and placing a notification inside that route. The error route runs only when the step breaks, and the notification tells you which automation and step failed. Then you force a fail once to confirm the alert works.
What is an error route in an automation?
An error route is a branch in your automation that runs only when a step fails. It catches the failure instead of letting the automation stop silently. Inside it you put your notification. In Make.com it is an error handler. In Power Automate it is a “Configure run after” setting set to trigger on failure.
Why does my automation fail without any warning?
Your automation fails without warning because it has no error route to catch the break. By default, most automations just stop when a step fails and produce no output. Without an alert branch, the silence looks identical to success. Adding one notification on the failure point fixes this.
How do I test an automation alert without waiting for a real failure?
You force a fail. Deliberately feed the failure point bad input, like a wrong API key or an invalid email address, then run the automation once. Confirm the notification arrives with the automation name, step, and error. Then restore the correct input. This proves the alert works before you rely on it.
Where should I send automation notifications?
Send them to a channel you check often and cannot ignore, such as email, SMS, or Slack. The best channel is the one you already watch every day. A notification sitting in a place you never open is the same as no notification at all.
Do I need to add an alert to every step of my automation?
No. Start with the single step most likely to fail, usually a call to an external service you do not control. Alerting every step creates noise that trains you to ignore alerts. Add one, let it earn your trust, then expand only if you need more coverage.
How long does it take to add an alert to an automation?
About ten minutes. Two minutes to find the failure point, three to add the error route, three to build the notification, and two to force a fail and confirm it works. This holds across Make.com, GoHighLevel, and Power Automate.
You do not need to instrument every workflow today. Pick your most important one and give it a single error route with a real notification. Then force a fail to prove it works.
Save this and add one alert this week. Start with your most important workflow.
… and see more of my posts in your Google results.