I have a workflow (NR_CA_W14_CalComMeetingSync_v1) with a webhook trigger (POST, path nr-ca-w14-calcom-meetings) that works perfectly when triggered manually with pinned/mock data — it processes correctly end to end and writes to our database as expected.
However, the production webhook URL fails consistently:
Any POST request to this URL — whether from our actual webhook sender (Cal.com) or a plain test tool (reqbin.com) — returns:
json
{"code":0,"message":"There was a problem executing the workflow"}
No execution appears in the Executions tab for these failed requests — not even as an error. n8n support confirmed via chat that the request does reach my workspace but fails during processing, which is why it never shows up in the execution list.
What I’ve already tried, with no change in behavior:
Deactivating and reactivating the workflow
Deleting the webhook trigger node and recreating it from scratch (same path, same HTTP method)
Confirming the workflow is “Published”/Active
Key detail: the workflow logic itself is confirmed correct — I tested it manually (Execute workflow with pinned data simulating the real payload) and it runs successfully through every node, correctly validates an HMAC signature, and writes the expected row to our database. So this really looks like an issue specific to the production webhook execution path, not the workflow design.
Has anyone run into this same “fails silently, not even in Executions” behavior on n8n Cloud? I’ve already opened a support ticket, but wanted to check if this is a known issue here too.
Hi @New_Rol_Sistem, running with pinned data skips the incoming webhook request, so it doesn’t rule out a problem in the Webhook node’s settings.
Could you create a separate workflow with just a fresh Webhook node, POST method, its generated random path, and Respond set to Immediately? Leave the options at their defaults, publish it, then POST {} with Content-Type: application/json to its Production URL. Keep your Cal.com workflow unchanged.
If that returns the same error, add this minimal workflow’s ID, the request timestamp and your n8n version to your existing support ticket and ask for the server-side exception. If it succeeds, share the original Webhook node’s JSON with secrets removed so we can check its settings.
Adding to Anshul’s isolation test, two things worth checking in parallel, because they fit “fails on the live URL, fine with pinned data, nothing in Executions” quite closely.
1. Workflow settings, save failed production executions. Open the workflow’s Settings and look at “Save failed production executions”. If it’s set to not save (or the default for your workspace is off), a production run that errors leaves nothing in the Executions list, which is exactly what you’re seeing. Set it to Save, send one request again, and you should get the failed execution with the node that threw.
2. The parts pinned data never touches. A manual run with pinned data skips everything the Webhook node does with the real request, so that’s where the difference usually is:
If you validate the Cal.com HMAC against the raw body, check the Webhook node’s Raw Body option. With it on, the body can arrive as binary instead of $json.body, so a Code node that reads the body can throw on live requests while the pinned version runs fine.
If Respond is set to “Using Respond to Webhook node”, any error before that node is reached comes back to the caller as that same generic “There was a problem executing the workflow”.
One more thing once it works: set an Error Workflow in the same Settings panel that alerts you. Right now the only one who sees this failure is Cal.com, and a webhook sender that gets errors may retry for a while and then stop, which would look like no new meetings rather than a failure.
This is a known class of silent production-webhook failures on n8n Cloud.
The request reaches your workspace but dies extremely early (before an execution record is created), which is why nothing appears in the Executions list.
Most effective fixes (in order)
1. Hard reset the webhook
• Deactivate the workflow
• Delete the Webhook Trigger node completely
• Save
• Add a brand-new Webhook Trigger node (use a slightly different path temporarily, e.g. nr-ca-w14-calcom-meetings-v2)
• Publish the workflow
• Test the new production URL
2. Check the very first nodes
Even though manual execution works, production mode can fail on:
• HMAC signature validation
• Any expression that uses $json / $body differently
• Credentials that are only resolved at production time
Temporarily disable the HMAC check and any early Code/IF nodes and test again.
3. Force a clean publish
• Make a tiny change (add a no-op Set node)
• Publish again
• Test
4. If it still returns the same error after a completely new webhook path, reply in your support ticket with:
• The exact new webhook path
• Timestamp of a failed test request
• Confirmation that manual execution still works
Support can then check the internal webhook-to-execution hand-off for your instance — this specific “code:0 / no execution record” pattern usually needs them to clear something on the Cloud side.
Keep HMAC validation enabled on that route. An unsigned test from ReqBin is meant to fail; it just tells you nothing about whether a genuine Cal.com payload works.
Two implementation details worth checking:
The Raw Body binary pitfall. If the body is exposed through $binary, read the underlying bytes rather than hashing the metadata object. Re-serializing isn’t guaranteed to preserve the exact bytes Cal.com signed.
Returning { error: ... } does not abort the workflow. In n8n, returning an error object from a Code node is still a successful execution step. Unless you explicitly route invalid signatures to a separate branch or throw an error, downstream nodes—including your database write—can still execute.
If the minimal test also fails, that reproduces the issue without your HMAC or database logic. Send support the workflow ID, request timestamp and response so they can trace the failure.
If that minimal test works, enable “Save failed production executions” on your main workflow and send one real test from Cal.com to catch where the execution actually halts.