A webhook that used to fire instantly and suddenly stops is one of the more disorienting Make.com problems, because nothing about the scenario itself changed. The instinct is to check the scenario’s modules for a bug. That is usually the wrong place to look. A webhook is a URL, a queue, and an activation state before it is ever a scenario, and a stall in any one of those three can look identical from the outside: requests go out, nothing happens, and the scenario’s own history shows nothing because the run never started.
Green run but empty output? Analyze your logs free.
What “instant” actually means for a webhook
A webhook’s defining feature is that it does not wait to be asked. Contrary to scheduled triggers, which periodically ask a service for new data, a webhook executes immediately once its URL receives a request. That immediacy is exactly why a stalled webhook is so confusing: there is no polling interval to blame, no “check again in 15 minutes” explanation available. If a request arrives and nothing happens, the failure is not a timing issue the way a scheduled trigger’s might be; something concrete stopped the request from reaching or starting the scenario.
Requests can queue instead of failing outright
Webhooks process requests as they arrive, and by default they process incoming requests in parallel, without waiting for one to finish before handling the next. A setting exists to force in-order processing instead, which trades throughput for a strict sequence. Under load, or when that in-order setting is enabled and one request is slow, incoming requests can back up in a processing queue rather than being rejected. From the outside this looks exactly like nothing happening: no error, no notification, just silence, because the request is technically still waiting rather than lost. Checking whether requests are queued rather than simply absent is the first fork in this diagnosis, since the fix for a backed-up queue is different from the fix for a request that never arrived at all.
A webhook can be automatically deactivated
Webhooks are not permanently on just because you created them once. A webhook that is not connected to any active scenario for more than 120 hours (5 days) is automatically deactivated, and a broken or no-longer-valid connection behind a webhook module can itself cause the module to fail before a request is ever processed. This matters most for webhooks tied to a scenario that was recently turned off, edited, or replaced: if the old webhook sat unattached for several days during that gap, it can be deactivated by the time you reconnect it, and it will silently accept requests that go nowhere rather than firing your scenario. Checking the webhook’s own status, not just the scenario’s, is worth doing whenever the gap between “it worked before” and “I’m troubleshooting now” spans several days.
Rate limits reject requests outright
Unlike a queue backup, a rate limit produces an explicit rejection. Make can process up to 300 incoming webhook requests per 10-second interval, and returns a 429 status code once that limit is exceeded. If the system sending requests to your webhook does not surface or log that 429 response, the sender may believe the request succeeded when it was actually rejected, which reads from the Make side as “nothing arrived” even though something was sent. This is worth checking specifically when the trigger volume spikes, a bulk import, a burst of events from an upstream system, rather than during steady, low-volume traffic.
Scheduled (polling) webhooks behave differently under error
Not every “webhook” module in Make behaves like the instant-trigger case above; some connectors offer a scheduled variant that polls on an interval instead of receiving pushed requests. For that scheduled form, the scenario runs on its defined schedule and stops after three unsuccessful attempts, which is a different failure shape entirely: a scenario that ran fine for a while and then simply stopped attempting further runs, rather than one that never received a request. If your “webhook” trigger is actually the scheduled variant, the schedule and the attempt count are where to look, not the instant-trigger queue behavior described above.
Confirming what actually happened to a specific request
Once you suspect a specific missed event, the fastest way to confirm which of the above happened is to check the scenario’s own run history for that time window, not to resend the request and hope. If the history shows no run at all for that time, the request either never reached the webhook, was rejected by the rate limit, or hit a deactivated webhook, none of which leave a scenario-side run to inspect. If the history shows a run that started late, a queue backup is the likely explanation. If the history shows the run happened and produced the expected result, the problem was never the webhook at all, and the investigation belongs in the scenario’s own modules instead.
A webhook failing is not the same as a scenario failing
It is worth keeping these two as separate questions even though they feel like the same complaint. A webhook-level failure, deactivation, a rejected 429, a request that never arrives, means the scenario never starts at all, and its own run history for that period will show nothing, not even a failed run. A scenario-level failure means the webhook did its job, the request was received and the scenario started, but something inside the scenario’s own modules then went wrong, which will show up in the run history as an actual run with an error status. Confirming which category you are in, a wholly absent run versus a real but failed one, points the rest of the investigation in the right direction immediately.
When you cannot tell from the history alone whether the problem is the sending system or the webhook itself, take the sending system out of the equation entirely. Sending a manual test request to the webhook’s URL, from a browser, a command-line tool, or any request-sending utility, confirms whether the webhook itself accepts and processes a request at all, independent of whatever upstream system normally calls it. If a manual test request triggers the scenario correctly, the webhook and scenario are both fine, and the problem is specific to whatever the real sending system is doing, a malformed request, a wrong URL, a network restriction on its end. If a manual test request also fails to trigger anything, the problem is confirmed to be on the Make side, the webhook’s own status, the queue, or the rate limit, and the sending system was never the issue.
A checklist for a webhook that stopped firing
Work through these in order rather than guessing which applies. First, check the webhook’s own status and last-active state, not just the scenario’s; a webhook detached from any scenario for several days may have auto-deactivated. Second, check whether “process data in order” is enabled and whether a slow request could be backing up the queue behind it. Third, check the sending system’s own logs for a 429 response, especially around a volume spike. Fourth, if the connector uses a scheduled (polling) webhook rather than an instant one, check the schedule and the unsuccessful-attempt count instead of the queue. Fifth, check the scenario’s run history for the specific time window in question before assuming the request never arrived at all.
Limitations
This is a manual diagnostic sequence for a specific missed or delayed webhook event; it does not monitor webhook health continuously, and it will not catch an intermittent problem you never go looking for. It does not change your webhook’s configuration, rate limit, or deactivation timers for you. It is not a substitute for logging on the sending system’s side, which is often the only place a rejected or unsent request is visible at all.
This article was drafted with AI assistance and checked against cited sources through ScenarioTrace’s editorial workflow. Last updated: 2026-07-22.
Make and Make.com are trademarks of their respective owner. ScenarioTrace is an independent tool and is not affiliated with or endorsed by Make.