Field guide · n8n production webhook
A 200 response is not proof that n8n created an execution.
When a production webhook returns success, times out, or appears active while the Executions list stays empty, prove three separate boundaries: HTTP ingress, n8n execution creation, and the final business outcome.
Version 1.0.0
Generate one correlation-first evidence report.
The Bash checker sends a minimal synthetic GET or POST only after an exact side-effect safety confirmation. It records transport status and timing, omits the target URL and response body, and gives you one correlation ID to match in proxy and n8n logs.
Inspect it, make the trigger safe, then run it
curl -O https://agent-rescue-desk.netlify.app/n8n-webhook-ingress-check.sh
less n8n-webhook-ingress-check.sh
# Use a clone or sandbox, or disable every irreversible side effect first.
bash n8n-webhook-ingress-check.sh \
--confirm-no-irreversible-side-effects \
https://n8n.example.com/webhook/your-safe-probe \
POST
The checker refuses user information, query strings, fragments,
custom credentials, cleartext remote HTTP, and
/webhook-test/. It sends a synthetic JSON object—not a
customer payload—and never follows a redirect.
Read the three boundaries separately
Investigate the exact production path and method, published state, webhook registration, receiving hostname, proxy rewrite, and queue-mode routing.
Start at the first failed node. Check response mode, payload size, binary handling, worker availability, timeout, memory, and the first divergent input shape.
Trace the downstream state with the same idempotency key. A green run is not proof that the CRM, message, file, booking, or payment changed.
Why an HTTP 200 can mislead
The caller sees an HTTP response from whichever layer answered: load balancer, reverse proxy, n8n webhook process, main process, or a workflow response node. That response alone does not identify which layer handled the request and does not prove that a worker started the intended workflow.
- Search the ingress logs using the report's UTC timestamp and correlation ID.
- Search n8n Executions for the same time and workflow.
- Record the execution ID—or explicitly record that none exists.
- Verify the final external state separately.
Imported or deployed workflow only fires after a re-save?
Freeze the current state before toggling anything. Record the workflow ID, saved version, published or active state, deployment timestamp, and startup registration log. For n8n environments, source-control push and pull move the saved workflow; publishing on the receiving production instance remains a separate step.
A controlled re-publish can be a repair after that evidence exists. It is not a substitute for proving which workflow revision and trigger registration production was actually using.
Official references
Need the complete incident order?
Turn the redacted evidence into a bounded runbook.
The $49 machine-delivered runbook provides evidence order, stop conditions, rollback boundaries, and a final verification contract. The $1,000 rescue is reserved for one accepted production path that requires implementation.