When Make Goes Down: A Survival Guide for Your Team

Your Make scenario syncs new orders from your store into your accounting tool and notifies your team. It's run flawlessly for months. Today, orders are coming in but nothing is syncing. The scenario isn't erroring — it's just not triggering. The webhook that feeds it stopped receiving data two hours ago, and your finance team is about to close the day with missing numbers.

What Happens on Your Team

The Operations Manager

Notices the accounting tool is missing today's orders. Checks Make — the scenario shows no recent executions. It's not failing, it's just not running. The trigger webhook isn't receiving the events that normally start the scenario. Spends an hour figuring out whether it's the source app, the webhook, or Make.

The real cost: When a Make trigger stops firing, the scenario goes quiet — no errors, no executions, no alerts. 'Quiet' looks identical to 'nothing happened today,' so the failure hides until someone notices missing downstream data.

What they should have had: A monitor on the trigger webhook endpoint and the source app's health. When the webhook stops responding or the source app goes down, the alert fires — pointing directly at where the chain broke instead of an hour of guesswork.

The Marketing Automation Specialist

Built a lead-nurture scenario: form submission → enrich → add to CRM → start email sequence. Leads stopped flowing into the CRM. The form's webhook to Make was returning errors after a form-platform change, so the scenario never received the data.

The real cost: Automation chains are only as strong as their first link. If the trigger webhook breaks, the entire downstream sequence silently stops. Leads pile up uncaptured, and the cost is invisible until a sales rep asks where the new leads went.

What they should have had: Monitoring on the webhook endpoint that feeds the scenario. A broken trigger surfaces immediately as a failed check, so the specialist fixes the integration before days of leads slip through.

The Small Business Owner

Relies on Make to connect their booking system, calendar, and SMS reminders. A connected app had an outage, and the scenario started failing mid-run — bookings synced but reminders didn't send. Customers missed appointments.

The real cost: Make scenarios often touch several apps, and any one of them going down can break the scenario partway. The result is partial automation — some steps run, others don't — which is confusing and customer-impacting.

What they should have had: Monitors on the key apps the scenario depends on. When the SMS provider or booking app goes down, the alert identifies the failing dependency, so the owner can warn customers or trigger a manual fallback.

Why Monitor Make?

Make is fully hosted, so you can't monitor their servers — but your automations depend on two things you CAN monitor: the webhook endpoints that trigger your scenarios, and the apps those scenarios connect to. When a trigger webhook stops responding or a connected service goes down, your scenarios fail, and Make won't always alert you in time.

What to Monitor

hook.make.com/your-webhook-idYour Make custom webhook trigger endpoint

your-app.com/api/healthAn app endpoint your scenarios depend on

status.make.comMake's platform status for service-level incidents

What You Should Actually Do

1Monitor your Make custom webhook trigger URLs — if a trigger stops responding, the scenario silently stops running
2Monitor the apps and endpoints your scenarios depend on — a connected service going down breaks the scenario partway
3Check Make's system status page during incidents, but rely on your own monitors for trigger and dependency issues
4Build a heartbeat: have a simple scenario hit a monitored endpoint on a schedule, so you can detect when Make stops executing
5Keep a direct alert channel (not routed through Make) so a Make outage doesn't suppress your downtime notifications

Make's Official Status Page

Make publishes real-time status at www.make.com/en/help/tools/system-status. Monitoristic doesn't replace this — it complements it. The official page tells you when Make reports an issue. Your own monitor tells you when your connection is affected, often before the status page updates. You also get push alerts instead of checking a webpage manually.

Make is hosted, so you can't watch their servers — but you can watch the two things that actually break your automations: the webhooks that trigger your scenarios and the apps they connect to. Most Make failures aren't Make going down; they're a trigger that stopped firing or a dependency that went offline. Monitoring those endpoints catches the silent failures that 'no executions today' would otherwise hide.

Frequently Asked Questions

Can I monitor Make scenarios for uptime? +

You can't monitor Make's servers directly, but you can monitor what actually breaks your scenarios: the webhook trigger endpoints and the apps your scenarios connect to. You can also build a heartbeat scenario that pings a monitored endpoint on a schedule to detect when Make stops executing.

Why did my Make scenario stop running without errors? +

If a scenario shows no recent executions and no errors, the trigger likely stopped firing — the webhook isn't receiving data, or the source app changed. Monitoring the trigger webhook endpoint catches this, since a silent trigger failure produces no error in Make itself.

How do I detect when a Make-connected app goes down? +

Set up monitors on the apps and endpoints your scenarios depend on. When a connected service goes down, your monitor alerts you and pinpoints the failing dependency — so you know why the scenario broke instead of debugging blind.

How is this different from Make's status page? +

Make's status page reports platform-wide incidents. It won't tell you that your specific trigger webhook stopped firing or that a connected app went down. Those scenario-specific failures only show up through monitoring the endpoints your scenarios actually use.