Why Do Chat Responses Timeout After 100 Seconds in n8n?

It appears that your workflow is running successfully—processing and producing the correct output—but the web request never “sees” it because it’s timing out after 100 seconds. In your case, when a request takes longer than 100 seconds (as in your 3‑minute execution), the external request endpoint (whether it’s a webhook or hosted chat) gives a 524 error, meaning the client’s connection is terminated long before the processing completes.

This behavior usually happens because:

1. The underlying network or reverse proxy (or n8n Cloud’s own gateway) imposes a hard timeout on webhook responses.
2. The long execution time (typical in complex AI workflows) exceeds that timeout even though n8n completes the execution later on.

To resolve or mitigate this issue, consider one or more of the following approaches:

• Shorten the execution time: Optimize parts of your workflow or consider splitting the operations so that no single response takes longer than the timeout period.
• Implement asynchronous processing: Instead of waiting on the webhook response, let the request trigger the workflow, then use another mechanism (for example, polling or a callback) to retrieve or notify the user about the result when the execution finishes.
• Redesign the user interaction: Consider showing a “processing” or “please wait” screen, then update the user when the long-running operation has completed, rather than waiting synchronously for the response.

This issue isn’t with the workflow’s logic itself—as your execution log shows the expected output—it’s just the fact that the client (or gateway) connection is closed after 100 seconds. You'll need to adjust your architecture or expectations around synchronous webhook responses if your operations are expected to take several minutes.