n8n production webhook returns 500 with no visible execution

Your workflow completes when you start it manually. As soon as a booking system, form or another service calls the production URL, it gets an error. At the same time, no matching entry appears in the execution list. You now need a traceable answer to three questions: was the event sent? What did the receiving system return? Was the expected record or operation created in the destination system?

This guide helps you separate the incoming event from the workflow that follows. It covers both n8n Cloud and self-hosted instances, and identifies which checks apply only to infrastructure you operate yourself.

The specific symptoms

A public report concerns a Cal.com integration on n8n Cloud. A manual run with prepared data writes the expected database record. Real requests to the production URL instead return There was a problem executing the workflow, with no visible execution entry. The author does not report a confirmed resolution. Q1

A second report explicitly describes HTTP 500 even after a new minimal production endpoint was published. The test URL and manual execution work, while a schedule also produces no visible automatic executions. These observations do not prove the suspected cloud-side cause. Q2

The relevant signs in your own case are:

• The sender reports a failed delivery attempt to the production URL.
• A manual execution with prepared data, or a request to the test URL, works.
• You cannot find a matching entry for the failed attempt under “Executions”.
• The expected appointment, contact, order or record is missing from the destination system, or its state is unclear.

That last point is operationally important. An HTTP error and a missing entry alone do not reliably establish what may already have happened. Check the destination before resending real events.

What the manual test proves, and what remains uncertain

A run using prepared input data shows that the processing steps exercised in that run can work. It does not test the same path as a real external request. The n8n documentation explicitly distinguishes the test URL from the production URL; the production endpoint requires a published workflow. The HTTP method and path are also part of the routing. Q3

Saving execution data matters just as much: successful and failed production executions have separate settings. If a record is missing from the interface, first check whether that type of run was supposed to be saved. Q4 Describe the finding precisely: “No visible entry at the test time” is better supported than “n8n definitely did not execute anything.”

Safe first steps: trace one request from start to finish

1. Define the affected operation. Write down what should arrive and what should happen in the destination system. For example, a specially created test appointment should produce exactly one clearly identifiable test record. Do not use a real customer booking as a test that can be repeated freely. Also record when the last demonstrably successful operation occurred.

2. Preserve the evidence from the sender. Capture the event identifier, sending time and time zone, HTTP method, response status and a short response excerpt. If the sender has no delivery history, mark that evidence as unavailable. Distinguish “event created” from “HTTP request confirmed as sent”. Do not include personal content or signing keys in a public error report.

3. Compare the endpoint actually being used. Read the production URL directly from the intended Webhook node and compare it with the sender’s configured URL. Check the selected method and whether the workflow is published. Look for any message about the same path and method already being in use. The documentation explicitly covers this mapping. Q3 Do not change the existing path as a precaution: the sender may continue using the old address.

4. Check what evidence should be visible. Read the settings for saving failed and successful production executions. Record their current values and the view or filters you are using. Keep existing requirements for hiding sensitive execution data in place. Q4 If saving behavior needs to change for diagnosis, the responsible person must define the scope and retention period. For now, it is enough to establish that an empty list is inconclusive when saving is disabled.

5. Compare a legitimate test with the destination result. Where possible, use the actual sender’s test function with harmless data and its intended authentication. Record a unique test identifier, then inspect both the response and the destination system. An arbitrary unsigned POST is not an equivalent test of a signed integration. Keep authorization or signature validation enabled on the production endpoint. Q1

6. Create a separate isolation test if necessary. A responsible administrator can prepare a separate test workflow with suitable access protection, a new path, the correct method, an immediate response and no downstream business actions. Leave the production workflow unchanged. Record the result accurately. If this minimal endpoint also fails, it provides useful evidence for escalation; if it works, investigate what differs in the actual integration. The community suggests a separate minimal test, whose safe setup needs to suit your environment. Q1

7. Distinguish cloud hosting from infrastructure you operate. With n8n Cloud, a possible internal failure while handling an incoming request may need investigation by n8n. Use the appropriate support channel to provide the workflow ID, test time, response and isolation-test result. For a self-hosted installation, the responsible administrator should also examine the public webhook URL and reverse proxy. The official configuration guide covers URL generation and forwarded headers. Q6 These server settings are not a repair option for a cloud customer without access to that infrastructure.

How to verify that the process is working again

Agree on a controlled run from the sender through to the destination. A clearly identified test event must receive a traceable response and produce the intended result. Check the destination record directly. An early successful HTTP response alone does not confirm that later processing steps succeeded.

Next, record which events may be missing from the outage period. Reconcile them using their identifiers before deciding to process them again. This allows unresolved events to be handled deliberately and helps avoid unnecessary duplicate processing. Your workflow’s behavior on retries needs its own verification; this guide does not promise automatic protection against lost or duplicated events.

Frequently asked questions

Why does a manual run work while the production URL fails?

The requests take different paths into the workflow. Prepared data does not provide an equivalent test of receiving a real request. Check the URL type, method and publication status, then compare a legitimate external test with the result in the destination system. Q1 Q3

Does an empty execution list prove that no workflow ran?

It initially establishes only that no entry is visible. Settings for saving production executions are therefore among the first things to check. Also inspect the actual state in the destination system before replaying an event. Q4

Should I disable HMAC or other access controls for diagnosis?

Keep the safeguards on the production endpoint that handles your business process. Use a correctly authenticated test from the actual sender. If the incoming request needs to be isolated, use a separate test workflow without downstream business actions. A rejected unauthorized request does not itself establish that the webhook is faulty. Q1

Will an Error Workflow catch every lost event?

It does not replace a full reconciliation with the sender. The n8n documentation describes different data for trigger failures; the availability of an execution ID and URL depends, among other things, on whether the execution is saved. An absence of alerts must therefore not be treated as proof that all expected events were processed. Q5

Is this a confirmed n8n Cloud defect?

The reports examined show similar symptoms and are tagged as unconfirmed bugs. They do not establish a common cause or a specific version in which it was fixed. The generic error message is insufficient to identify the cause. Q1 Q2

Can an external service provider always fix it directly?

A local integration configuration can be investigated within the access and responsibilities available. A fault inside a managed provider environment may require that provider’s involvement. A useful engagement may therefore consist of documenting the failure, preparing a complete support case and verifying the business process after the issue has been resolved.

Where to get help

The official guidance on the Webhook node and workflow settings is a useful starting point. Q3 Q4 The n8n Community is an established place to discuss sanitized configurations, test procedures and version details; both original reports are posted there. Q1 Q2 Findings that require internal cloud investigation belong in the support channel for your own n8n account. Public posts should not contain the full production webhook path, customer data or secrets.

Describe your issue

Is your booking, lead or data transfer getting stuck? Tell KAN KAI which system sends the event, what should happen in the destination, and the details of one specific failed delivery attempt. The test time, response status, hosting model and destination check help determine whether you need integration support, diagnosis in your own environment or an evidence-based escalation to n8n.

Include in your request: n8n Cloud or self-hosted · version, if known · event type · expected result · last successful operation · error message and test time · checks already performed. Do not initially send complete workflow exports, production credentials or real customer payloads.