What is your goal?
Curious how others handle this, especially if you run scenarios for clients.
What is the problem & what have you tried?
When a run fails, Make tells you: error emails, incomplete executions, and eventually the scenario gets deactivated.
But I keep hearing about a different case:
the scenario is still active and just stops receiving anything.
A webhook stops getting called, the source app changes something, or a connection expires upstream. Nothing runs, so nothing errors.
Has this happened to you?
What stopped, and roughly when?
How long before you noticed, and who noticed first, you or the client?
Do you have anything set up now to catch it, or do you just check the history now and then?
Make can only alert on a run that starts and fails. If the webhook is never called, there is no execution to report, so I monitor freshness separately from errors.
After the last successful business action, write `{scenario, last_received_at, last_processed_at, source_cursor}` to a Data Store or external table. A separate scheduled health-check compares those timestamps with the expected arrival window and alerts when either is stale. Keep received and processed separate: the first catches an upstream/webhook problem, the second catches a scenario that received data but stopped before the final write.
For important webhooks I also send a synthetic canary event on a schedule, or verify delivery from the source app. Run the monitor through a different scenario and connection; otherwise the same failure can silence both the automation and its alarm.
Hello,
In that case source of the problem is outside Make and there is no one-size-fits-all scenario to handle it. You will go with different approach to CRM and OMS.
And in general, everything depends on expected SLA and importance of processed data. Also, there is no one solution for all use cases.
For sure, good architecture and knowing process can help you a lot to use correct error handlers or extra notifiers, like calls to API or sending email/messages, whatever you are using.
Here is what happened. Couple of months back some folks imagined that such cases exist in Make and are a common issue that needs solving. Then they built a “solution” that you need to pay for, that supposedly tracks these issues and alerts you.
These are not common issues. Most people will never see these happen.
A scenario will never magically stop working on its own. You will get an alert for a connection expiring. Any service worth their salt will also send you an alert if it cant call the Make webhook its supposed to. And if you actually have a service that silently fails, all you need is either a secondary scenario that checks if the first scenario ran today (or this week, or however frequently it runs) and alert you, or have the scenario feed a watchdog that alerts you when it wasn’t fed.
Also, all these “solutions” out there are basically using my first recommendation. They are making an API call to Make to check if the scenario ran today.
I agree with the points above. Adding a few things from our experience:
We’ve built an internal solution for monitoring scenarios across our clients, and we use email as a trigger for anything that needs to run in real time.
A few practices that I find useful when managing a lot of scenarios:
1. Leveraging the incomplete executions (DLQs). Structure scenarios into small, modular pieces so they’re easy to troubleshoot and retry when something unexpected happens. Another advantage of DLQs is they are clearly shown as outstanding on the grid.
2. Raising custom errors on purpose. I throw errors with custom messages to deliberately trigger the error path. You can easily do this by creating a scenario with a webhook and webhook response module.
Roughly how many client scenarios does it cover, and how much time does it take to maintain? Does it catch scenarios that just stop receiving data, or mainly errors?
I’d monitor expected activity, not only errors.
If a workflow should receive at least one event every business day, keep a tiny heartbeat record with last_expected_event_at.
A separate check can alert only when the workflow has been silent longer than the normal business window.
For lower-frequency flows I’d monitor the business outcome instead.
Example: if an order source normally creates records, compare source/order counts with confirmed destination writes rather than asking only whether the Make scenario ran.
That avoids two false assumptions:
The threshold should be workflow-specific.
A daily order feed going silent for 6 hours may matter. A monthly renewal workflow going silent for 20 days may be perfectly normal.
The most useful alert is usually:
expected activity missing / last confirmed outcome / owner / next check.
What have all of you smoked? Are we discussing silly potentials on a non-issue here?