Your n8n workflow didn't break. It stopped being told.

The symptom everyone misreports

Almost every ticket starts the same way: "n8n is down." It isn't. The instance is healthy, the editor loads, and the workflow shows a calm, empty execution list. What actually changed is upstream — the thing that used to call the webhook stopped calling it, or started calling a URL that no longer exists.

That distinction matters because it changes where you look first. You're not debugging n8n's execution engine. You're debugging whether the trigger was ever asked to run.

Three causes, in order of likelihood

1. The sending app rotated its webhook URL after an update or reinstall.
2. The production webhook never registered, so the URL is right and n8n answers it with a 404 anyway. The body names the method and path and adds the hint "The workflow must be active for a production URL to run successfully". Toggling the workflow off and on re-registers the same address — which is why "I turned it off and on and it came back" is a fix and not a coincidence.
3. Someone duplicated the workflow and wired the sender to the copy. What the copy inherits depends on which kind of path you have. A webhook left on the random path n8n generates gets a fresh URL when the workflow is duplicated. A path you typed yourself is copied verbatim — and since n8n registers only one workflow per path and method, activating the copy quietly takes the calls away from the original, which keeps its URL and stops being reached anyway. Exporting, importing and pasting the node into another workflow keep the address in both cases; deactivating and reactivating never change it.

A quick way to confirm the URL is still live is to ping it directly:

curl -i -X POST https://your-n8n-host/webhook/inbound-lead \
  -H "Content-Type: application/json" \
  -d '{"ping":"1"}'

What the pattern looks like

Silent trigger failures follow the same shape whatever caused them. The execution list stays clean, so every dashboard reports health, while the sending side quietly accumulates a backlog it will eventually give up on.

A workflow that fails loudly costs an hour. One that fails quietly costs a quarter of your pipeline.

What we'd check next

If the ping above returns anything other than a clean 2xx, stop guessing and verify the chain end to end before touching the workflow itself.

• Confirm the sending app's current webhook URL matches production
• Check whether the workflow was deactivated and reactivated recently
• Add a failure alert so a silent trigger is never silent twice