Practice surgery · no patient data

Make webhook not moving triage.

A field packet for Make.com scenarios where the webhook is “on,” a request appears to arrive, but the scenario does not advance — or a duplicated scenario loses the hook, or the first run works and the next one goes silent. No login. No client secrets. Just the cuts I would make in the first 20 minutes.

Receipt: built by Mikael on 2026-07-12 from public Make community traces. Not a client case. Not official Make advice.

Symptom cluster

What this failure looks like

Run once works; the next webhook call does not move through the scenario.
The webhook module says it is waiting, enabled, or missing a trigger, while the sender believes it sent data.
A cloned or duplicated scenario exists, but the old webhook URL or hook assignment is still in play.
OAuth verification fails before the useful request is even made.

The dangerous part is ambiguity: “webhook failed” can mean sender, URL, hook assignment, scheduling state, connection verification, or downstream module stop.

First incision

Do not rebuild first

Catch: did Make receive any request at the exact hook URL?
Move: did the execution leave module 1?
Bind: is this webhook assigned to the scenario you are watching?
Auth: did Make stop at connection verification before the webhook test?

Four different wounds can look like one dead automation. Name the wound before adding new modules.

20-minute table protocol

00:00-04:00 · freeze the evidence

Write down the exact patient

Copy the scenario name, module 1 webhook name, schedule/on-off state, and last visible execution time.
Copy the sender timestamp and destination timestamp. Redact names, emails, payload bodies, tokens, account IDs, and hook URLs before sharing publicly.
If this is a clone, record which scenario was cloned from which original.

04:00-08:00 · prove the catch

Separate “received” from “advanced”

Send one harmless sample payload to the current webhook URL.
Check whether Make records an execution at module 1. If not, suspect sender URL, hook assignment, inactive scenario, or copied/stale webhook.
If module 1 receives data but module 2 stays dark, the webhook is alive; the downstream path is the patient.

08:00-13:00 · inspect clones and hooks

Cloned scenarios deserve suspicion

Assume a duplicated scenario may need a fresh webhook endpoint and a fresh sender configuration.
Look for “hook already assigned” or a webhook that belongs to the old scenario.
Rename hooks with date/purpose while debugging. Future-you is also a patient.

13:00-20:00 · repair and canary

Revival is not one green test

Run two samples, not one: one after saving, one after toggling the scenario off/on.
If OAuth verification failed, re-test the connection before retrying the webhook path.
Add a canary: a daily count, error route, or alert when sender events exceed destination records.

Discharge note

A revived Make scenario is not “I clicked Run once.” A revived scenario is: the right hook is assigned to the right scenario, a fresh sample crosses module 1 twice, downstream movement is observed, and the next silent stop has an alarm.

Sources I actually checked

Make Community: “Webhook not moving through scenario” — public thread title around a webhook that does not progress through a scenario.

Make Community: “Clone scenario to update module” — scenario-clone context; search result noted duplicated webhook concerns in related threads.

Make Community: “My very simple scenario stops running after first go” — first-run-then-silent pattern tagged with Airtable and webhooks.

Make Community: OAuth 2.0 “Failed to verify connection” — connection verification failure that can masquerade as a webhook problem.

Make Community: “Webhook Error” — sparse public thread; useful mostly as a reminder to collect exact status, payload, headers, and module screenshots.

Public forum extracts were sparse, so this packet stays conservative: it names safe triage questions instead of pretending to know a private root cause.