MAKE WEBHOOKS

Make webhook not triggering the scenario: check the Logs tab first

Short answer: in Make, open Webhooks in the left menu, pick your webhook, and look at its Logs and Queue tabs. If the call is in the logs, Make received it and the problem is in how the scenario processes it. If the call is not in the logs, the request never reached Make, and the problem is on the sending side or in the URL.

Make's webhook documentation covers every behaviour below, but it is spread across one long page. This guide turns it into an order of checks. Your scenario's specific modules and your sending app are not covered here, because we cannot see them.

Step 1: did Make get the request?

Go to Webhooks in the left sidebar, select the webhook, and switch to the Logs tab. Make keeps webhook logs for 3 days, or 30 days on the Enterprise plan. Each entry shows the status (success, warning or error), the date and time, and the log size. Click Detail to see the request (timestamp, URL, method, headers, query, body), the response, and the parsed items.

• Entry present, status success: Make received the data. Go to Step 3.
• Entry present, status error: read the Detail response. Go to Step 2.
• No entry: the call did not arrive. Check the URL in the sending app against the one in Make, character for character, and check whether the app shows its own delivery log.

Step 2: the response codes Make sends back

Per Make, without a Webhook response module the defaults are:

• 200, "Accepted": the webhook went into the queue.
• 400, "Queue is full": the queue is full, and Make rejects all incoming data over the limit.
• 429, "Too many requests": the rate limit check failed. Make can process up to 300 incoming requests per 10 second interval.

A third one matters if the webhook has sat unused. Make automatically deactivates webhooks that are not connected to any scenario for more than 5 days (120 hours), and the hook returns a 410 Gone status. If the sending app reports a 410, the fix is to reconnect the webhook to a scenario, or create a fresh one and update the URL in the sending app. That reconnect step is our reading of the situation, not wording from Make.

Step 3: the call arrived but the scenario did not run

Make stores each request in the webhook's own queue. Open the Queue tab and look.

Is the scenario on a schedule? By default, a scenario with a webhook runs immediately when data arrives. But you can schedule webhook processing, in which case Make holds data in the queue and processes the whole queue only when the schedule is due. Check the scenario's schedule settings, or the schedule settings of the webhook module.

Is the queue draining slowly? For scheduled webhooks Make processes items based on the Maximum number of results setting. Make's example: with an hourly schedule and the default of 2, it processes two items every hour. If the queue is filling up, raise that number or run the scenario more often. Instant trigger modules use Maximum number of cycles instead.

Did the scenario stop after an error? Make says that when a scenario with a webhook hits an error, it stops immediately if set to run Immediately, or after 3 unsuccessful attempts if it runs on a schedule. Open the scenario's execution history. If a failed run is the last thing there, fix that error and run it again.

Are you waiting your turn? By default instant webhooks are processed in parallel. If you switched on Process data in order in the scenario settings, Make waits for the previous execution to finish before starting the next. A slow or stuck run in front of the rest looks like nothing is happening.

Step 4: the response module and your credits

If you use the Webhook response module, where you put it matters. Make warns that if it sits in the middle of a scenario and a later module errors, the scenario will not be deactivated. That can increase credit use because you do not get notified of the error. If the response module is last, you are notified of an error at any point. Check where yours sits.

Step 5: queue size

Make says the maximum queue length depends on your plan's usage allowance. For every 10,000 credits licensed per month you can have up to 667 items in each webhook's queue, and the maximum is 10,000 items. When it is full, new data is refused, which matches the 400 response above.

To clear old test items, go to Webhooks, select the webhook, open the Queue tab, tick the entries and click Delete selected, or tick the first box to delete all and confirm. Make says that incoming data is always stored in the queue, and is permanently deleted once the scenario processes it.

If your problem is a different one

If the webhook arrives and the scenario runs but fails, or the whole scenario is switched off, that is a different problem: look at the scenario's own execution history and its on/off switch. If you use n8n instead of Make, the checks differ, because n8n has separate test and production webhook URLs.

When to hire help

Hire help when the logs show the call arriving but you cannot work out why the scenario ignores it, when orders or leads are being lost while you investigate, or when you need the sending side fixed too. Webhook problems are two systems talking, and that is where people lose days.

Send us the webhook's log entry (with anything private removed), the app that calls it, and the scenario's schedule setting. We will tell you what we found and agree the price first. One defined defect is a fixed $299, with the $99 diagnosis credited. Larger work gets a written quote. We never ask for your password: tell us what is happening.