Your automations already know when they fail. Put that in a channel Ray reads.Put that in a channel Ray reads.Put that in a channel Ray reads.

Create a channel called #automation-alerts, or reuse the one your alerts already land in. Invite Ray the way you would invite a teammate, with /invite @Ray. Give the channel a topic that says what lands there, so the next person who joins knows too.

• One channel for all three tools. Ray groups by automation when you ask.
• Keep conversation out of it. Fewer messages means a faster read-back.
• Public or private both work. Ray reads what it is invited to and nothing else.

Zapier’s own app, Zapier Manager, fires when one of your Zaps errors or gets turned off. Pair it with a Slack step and the alert lands in your channel with a link back to the Zap. It is two steps, so it runs on Zapier’s free plan.

1. 1.Sign in as the person who created the Zaps you want watched. On Team and Enterprise plans the error goes to the Zap’s creator, and Zapier Manager only sees errors on Zaps that account owns.
2. 2.Check that error emails are on. Open Settings, then Notifications, then My notification settings, and set your default notification frequency to anything other than Never. Zapier Manager only fires for Zaps that would have emailed you.
3. 3.Create the alert Zap, or start from Zapier’s template Send Slack notifications if your Zaps run into errors. Trigger: Zapier Manager, New Zap Error. Action: Slack, Send Channel Message, into #automation-alerts. Put the Zap’s title, the edit link and the error text in the message, in that order.
4. 4.Create a second Zap for Zap Turned Off, with the same Slack step. Zapier switches a Zap off after repeated errors, and a Zap that is off raises no more errors.

Worth knowing

• The error trigger fires only after Zapier has finished its automatic replays, so an alert can land a while after the first failure.
• When an error handler catches the error, Zapier sends no email, and Zapier Manager sees nothing either.
• In November 2025 Zapier staff confirmed that New Zap Error was not firing reliably, with no fix date. Keep the email notifications on as a backstop.

Make posts errors from inside the scenario, one error route per module, and emails you when it deactivates a scenario. The first is a Slack message you design. The second is email only, so it needs a forward.

1. 1.Add an error route. In the scenario editor, right-click the module that can fail and choose Add error handler. Start with the modules that call outside services. Step 4 catches what the rest miss.
2. 2.Post from the route. Add Slack, Create a Message, into #automation-alerts. Use the scenario name, the error message and the execution id from Make’s variables, so the alert says which scenario, what broke and which run.
3. 3.End the route with a directive, such as Resume or Skip, so the run continues and the alert still goes out.
4. 4.Forward the deactivation email. Make disables a scenario’s schedule after a run of consecutive errors and tells you by email, with no Slack option. A three-module scenario forwards it: a Custom mailhook trigger, a filter on the subject so only deactivation notices pass, and Slack, Create a Message. The same hook receives Make’s per-run error emails and digests, which is why the filter matters.

Worth knowing

• With Store incomplete executions switched on, an error becomes a warning and the run parks in Incomplete executions. Nothing posts unless your error route does.
• Once your error routes post to Slack, keep Deactivation on in Make's email preferences and switch Errors and Warnings off. A module with no route then only surfaces at deactivation, and the error emails stop.

n8n has the cleanest answer of the three: an error workflow that runs whenever a production workflow fails, carrying the workflow’s name, the error message and a link to the failed execution.

1. 1.Create a workflow that starts with the Error Trigger node.
2. 2.Add a Slack node, Send a message, into #automation-alerts, using the workflow name, the error message and the execution link the trigger hands you.
3. 3.Point each production workflow at it. Open the workflow, then Options, Settings, Error workflow, pick yours, Save. One error workflow can serve every workflow you have.

Worth knowing

• Manual test runs never fire the error workflow. Only automatic executions do.
• The error workflow does not need publishing. It runs as long as a workflow points at it.
• Each workflow needs the setting on its own. There is no instance-wide default, though a community template attaches it in bulk through n8n's API.
• If your n8n runs on a private host, the execution link only opens from inside your network.

Pipedream emails once per error per workflow per day by default. A workflow subscribed to the Workspace $error events source receives every error as it happens, with the original event attached, and a Slack step forwards it.

Activepieces sends project alerts by email only, a handful an hour at most. Forward the email, or post from inside the flow when a step fails.

Power Automate emails a flow’s owners about known, fixable failures and then holds off for 28 days on that flow. For everything else, add a branch that runs only when a step has failed and post through the Slack connector.

Ray reads the alerts as they arrive, like any channel it is invited to. It stays quiet unless something clearly needs a person, and it asks before it changes anything. Ask it what happened.

Ray reads the night back, groups the repeats, and answers with which automations failed, how many times, and the last error for each.

Creating the issue is a write, so Ray shows you the card first. The ticket exists only after someone approves it.

That is a scheduled digest. It runs without anyone asking.

Priya

@Ray anything still failing from last night?

Ray

Two of nine. The HubSpot lead sync Zap failed four times, last error “invalid property value” at 03:12, and the Shopify to Sheets scenario is deactivated after three errors in a row. The other seven recovered on their own.

Worth reading before you rely on it. Ray says these things itself when they come up, but here they are in one place.

• It cannot re-run, pause, edit or switch off a Zap, a scenario or a workflow through this channel. Fixing the automation still happens in Zapier, Make or n8n.
• It sees only what the vendor posts. A Make run parked in Incomplete executions, or a Zap error that Zapier Manager missed, never reaches the channel and never reaches Ray.
• Reading a channel's history back is rate-limited by Slack, so a busy night takes Ray a few minutes to read back. Ask as alerts land and the answer is immediate.
• It does not page you. Ray may speak up when a message clearly needs a person, but for a push you can rely on, set the digest.
• It reads the alert text and nothing behind it. If the message says only “error”, Ray can tell you an automation failed and not why. Put the error message in the alert.