Workflow with Respond to Webhook does not reply a 500 status error when failing

[ebarault]

Bug Description

Consider the following test workflow where the webhook is configured to respond using 'Respond to Webhook' Node:

According to the doc here:

The workflow errors before the first Respond to Webhook node executes: the workflow returns an error message with a 500 status.

So, when executing the workflow via the webhook, and the workflow failing at the Debug node, the workflow should respond an error message with a 500 status. But instead, the webhook returns a 200 OK when an empty body.

To Reproduce

Build a similar workflow, and call the associated webhook url.
The webhook responds an empty message with 200 status code

{
  "name": "test_webhook",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "1fcc15ad-868f-47b8-86dd-ecbbbda6dfe8",
        "authentication": "headerAuth",
        "responseMode": "responseNode",
        "options": {}
      },
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2.1,
      "position": [
        0,
        0
      ],
      "id": "5755594d-539e-45e1-ac06-089654fb81f6",
      "name": "Webhook",
      "webhookId": "1fcc15ad-868f-47b8-86dd-ecbbbda6dfe8",
      "credentials": {
        "httpHeaderAuth": {
          "id": "n8n_webhook_bearer_auth",
          "name": "n8n_webhook_bearer_auth"
        }
      }
    },
    {
      "parameters": {
        "amount": 3
      },
      "type": "n8n-nodes-base.wait",
      "typeVersion": 1.1,
      "position": [
        224,
        0
      ],
      "id": "4f1a51de-3317-41bd-b9b6-477f27eab4c4",
      "name": "Wait",
      "webhookId": "e4e7170d-31fd-4dc3-8ade-f9e410f1e75d"
    },
    {
      "parameters": {},
      "type": "n8n-nodes-base.debugHelper",
      "typeVersion": 1,
      "position": [
        464,
        0
      ],
      "id": "f0db3f7e-a567-4308-9d32-200d8b4b15dc",
      "name": "DebugHelper",
      "alwaysOutputData": false
    },
    {
      "parameters": {
        "respondWith": "json",
        "responseBody": "{\n  \"statusCode\": 200,\n  \"body\": { \"status\": \"ok\" }\n}",
        "options": {
          "responseCode": 200
        }
      },
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1.4,
      "position": [
        704,
        0
      ],
      "id": "0a9336d6-d70f-41bb-aefb-7d5a1ce18c71",
      "name": "Respond to Webhook"
    }
  ],
  "pinData": {},
  "connections": {
    "Webhook": {
      "main": [
        [
          {
            "node": "Wait",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Wait": {
      "main": [
        [
          {
            "node": "DebugHelper",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "DebugHelper": {
      "main": [
        [
          {
            "node": "Respond to Webhook",
            "type": "main",
            "index": 0
          }
        ],
        []
      ]
    }
  },
  "active": true,
  "settings": {
    "executionOrder": "v1",
    "callerPolicy": "workflowsFromSameOwner",
    "availableInMCP": false
  },
  "versionId": "6228ce12-9f57-41f7-a5eb-524457d19cea",
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": "997b06b96c0f4f8fb033a6ba85f16f24d5448cd1de2de0d24ca01140698467f6"
  },
  "id": "NcdWdq6Ku3MDydZa",
  "tags": []
}

Expected behavior

the webhook should respond an error message with a 500 status code

Debug Info

Debug info

core

• n8nVersion: 1.119.0
• platform: docker (self-hosted)
• nodeJsVersion: 22.21.0
• nodeEnv: production
• database: postgres
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: d1a0d430-fc98-426b-a0e3-bc299f9f2cb4

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: memory

pruning

• enabled: true
• maxAge: 336 hours
• maxCount: 10000 executions

client

• userAgent: mozilla/5.0 (macintosh; intel mac os x 10_15_7) applewebkit/537.36 (khtml, like gecko) chrome/141.0.0.0 safari/537.36
• isTouchDevice: false

security

• secureCookie: false

Generated at: 2025-11-13T15:02:59.906Z

Operating System

Official Docker image running on Amazon Linux 2023

n8n Version

1.119.0

Node.js Version

22.21.0

Database

PostgreSQL

Execution mode

main (default)

Hosting

self hosted

[n8n-assistant]

Hey @ebarault,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-5477".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-5477

[kumbhanChoksi]

This is an expected behaviour. To achieve what you want navigate to settings => on Error => Select Continue (using Error output). Then attach the error edge to Respond to Webhook node. Refer to screenshots below:

And for the response logic, you'll have to configure the response code field using the javascript expression to select 200 or 500 status codes. Refer to the screenshot below:

[ebarault]

hi @kumbhanChoksi
Thanks for replying.

What you suggest is indeed my workaround, but then if is the right way to do it, then the doc here is either wrong or misleading

The workflow errors before the first Respond to Webhook node executes: the workflow returns an error message with a 500 status.

In my understanding, we are exactly in the case the error occurs before the first Respond to Webhook node executes

[kumbhanChoksi]

Hi @ebarault. You’re right! The current behaviour doesn’t fully align with what the docs say.

[kumbhanChoksi]

What I observed:

• When a node throws an error and onError = continue is not enabled, the workflow execution stops.
  In this case, the Webhook node returns a 200 response by default.
• When onError = continue is enabled, the workflow continues and reaches the Respond to Webhook node.
  However, the Respond to Webhook node always returns 200 unless a custom response code is set. It does not check whether an upstream node has thrown an error.
• The documentation, however, says that Respond to Webhook should return 500 if an upstream node has thrown an error. This behavior is currently missing and could be fixed by adding an upstream-error check in the node.
• There is also a second scenario: when the workflow stops before reaching the Respond to Webhook node. In this case, the Webhook node is the one that returns the HTTP response. Here too, it would need to detect the execution error and return 500 instead of the default 200.

[n8n-assistant]

Hi @ebarault 👋

Thanks so much for your patience while we’ve been improving n8n. We know it’s taken some time to review this issue, and we’re currently updating our triage process to better keep up with our growth.

There have been a lot of improvements in recent releases, so we’d really appreciate it if you could check whether this issue still occurs in the latest release.

When you have a moment, please copy and paste the checklist below as a comment so our system can update the status automatically:

[ ] I have updated to the latest stable version of n8n [please specify version number] and I am still experiencing this issue
[ ] Please close this issue – I am no longer experiencing it
[ ] Please close this issue – [please specify a reason]

If we don’t hear from you in the next 14 days this issue will be automatically closed, feel free to reopen - don’t forget to add the checklist above so that our automated systems notify us of the issue.

Thanks again for helping us keep n8n healthy and up-to-date 💚

[n8n-assistant]

As we haven’t heard back from you, we’re going to close this issue to keep things organized. But don’t worry, if you have more information or need further assistance, you’re welcome to reopen the issue anytime or create a new one. We’re always happy to help!

Thanks for reaching out and have a great day! If this was closed by mistake and you have been waiting for us let me know and I can also re-open it.

[webbdeneys]

Yeah just an opinion here this is a very bad behavior. So the suggested workaround is to decorate every single node in a workflow with a route to the 'return to webook' entry to get this to behave correctly (and as documented, but if somebody updates the documentation I'd argue that is still a bug - a call that 'barfs' should not return success unless the webhook was configured to return a 200 immediately).

[itschasa]

Can this be changed? This seems like very weird behaviour how an error is returning a 200.