MAKE WEBHOOKS
Make webhook queue overflow — oldest payloads dropped first
When a Make scenario is off or processing slowly, inbound webhook payloads queue — up to a cap. Once full, payloads are discarded, and senders saw acknowledgements the whole time. It’s a silent drop with a receipt.
Why Make webhooks fail silently
Scenario off + traffic still flowing
Senders don’t know (or care) that your scenario is paused — payloads keep arriving and queueing.
Slow scenarios drain slower than fill
A scenario processing one bundle every few seconds can’t keep up with bursty senders — the queue becomes a slow-motion overflow.
No sender-side signal
The webhook endpoint accepts payloads before queueing — the sender’s success log is a false signal of delivery.
The fix
- 1
Check queue depth on every custom webhook
Make shows the queue per webhook — anything non-zero means flow is outrunning processing.
- 2
Speed up or parallelize the scenario
Reduce modules per run, enable sequential processing where ordering matters, or split high-volume flows.
- 3
Pause senders before long maintenance
If you’re disabling a scenario, stop or redirect the senders first — the queue is not a safety net.
- 4
Monitor the fill rate externally
HookShield timestamps every inbound event — the gap between arrivals and executions is measurable, alertable data.
DEAD-MAN'S SWITCH
Never find out about a dead webhook from a customer again
Point Make at a HookShield ingest URL. Every delivery is logged, signed, and forwarded — and if pings stop arriving, you're alerted before the silence becomes an incident.