I have a workflow that contains an input form, where I simply capture some text, which then gets processed and formatted through an AI Agent node. I have a form ending node that should simply display the structured and formatted html content from prior nodes.
It seemed to be working until last week, now all of a sudden, the form node runs forever (spinning) and never fnishes. The workflow itself finishes (because I Have set the “limit execution time” to 0.50 minutes). But the form ending node keeps spinning and spinning and spinning.
This behavior is expected based on how n8n Forms work.
Per the docs, a Form Trigger keeps the HTTP request open until a Form Ending node sends the response. If the workflow finishes (timeout, error, or early exit) before that happens, the form UI will keep spinning.
Common causes in this setup
The AI Agent takes too long
Execution hits the time limit before Form Ending runs
A branch does not reach the Form Ending node
How to fix
Make sure every execution path reaches exactly one Form Ending node
Keep Form workflows short and synchronous
Move slow AI processing to a separate workflow and return the form response immediately
Ensure the Form Ending node is the last step executed
This matches the documented pattern: Form Trigger → processing → Form Ending, without long-running or async steps.
Thanks, but looking at your feedback, none of those occur. The AI agent processes it pretty decently. Form ending node is exactly the last node.
I though immediately that the additional branch (code node > Outlook node) are causing the problem, but even without them, the form ending node keeps spinning.
Your statement in regards to long-running async steps does not make sense to me, tbh. Isn’t that the overall purpose of tools like n8n? Taking some kind of input through a form > process through AI > show the result?
Plus it has been working before so why does it all of a sudden stop.
Hey @inservo I have tested the workflow with my credentials and it works really well as i have expected it to, it asks the user about the idea evaluates it and then shares the output in the ending and shows the MarkDown→HTML output in the ending, what is causing you the problem exactly in your main workflow?
I basically found one difference I had, however, it is still not working.
I exchanged the form ending node for a “next form page” node because what i basically want to do is to go through some iterations and with the help of AI improve the response until is good enough to be submitted.
Not in the workflow I shared (very simple one) but in general, that is the idea.
However, no matter if I choose form ending page or next form page, it never renders and never stops spinning. Does that basically mean you cannot use AI thinking models inbetween form pages as they have dynamic thinking times (that would be quite disappointing and unlogical from my point of view)?
My problem is that it never shows the HTML output and keeps the Form Ending node spinning, never rendering anything. It stays “stuck” on the submission page.
When i have tried it without changing anything in the flow it shows me the HTML as is when the AI finishes generating the output, and works just fine as you want it to be, have you tried switching to a different mode? or using Webhooks instead of forms?
But this let’s me question n8n completely. What’s the purpose of having a tool like n8n that has AI in its DNA if I can’t basically use these AI capabilities together with a simple user interface like forms.
You seem to say: only use forms if you don’t want to use AI.
Makes absolutelty no sense to me because what would I do with the form submission? For pure data handling there are much more convenient tools than n8n. Where n8n for me really shines is the use of AI
I completely understand why you feel this way. Your frustration is entirely valid. When you have a powerful AI tool like n8n, the expectation is that you can use it seamlessly with a simple UI like a form. The current technical limitation forces a design pattern that feels overly complex for what should be a straightforward task.
The issue isn’t a lack of capability in n8n, but a conflict between the synchronous nature of web requests and the asynchronous nature of deep AI processing.
1. The Technical Reality (Why the Spinner)
As confirmed by the community and our internal teams, the core problem is that the AI Agent node, especially when using complex models like qwen3 thinking, takes too long.
Component
Requirement
Result of Conflict
Form Trigger
Must respond in < 1 second (Synchronous)
Times out and displays the infinite spinner.
AI Agent
Needs > 1 second (Asynchronous)
Cannot complete before the form times out.
The technical solution is the Asynchronous Architecture (Workflow A + Workflow B), which is the most stable and scalable method for production environments.
2. The Trade-Off: Why the Asynchronous Method is Recommended
The recommended Fire-and-Forget method solves the stability issue but introduces a trade-off: you lose the ability to show the AI result on the immediate “Thank You” page.
Method
Pros
Cons
Current (Synchronous)
Simple, single workflow.
Unstable, prone to timeouts, poor user experience.
Recommended (Asynchronous)
Stable, scalable, no timeouts.
Requires two workflows, result must be delivered via email or a separate page.
3. The “Third Way”: Trying to Keep the Result on the Page (Polling)
If your primary goal is to keep the result visible on the form’s final page, you can attempt a “Third Way,” but be aware that it is less stable and relies on the n8n Forms feature being able to handle a slight delay.
This method involves Polling or Waiting for a short period, hoping the AI finishes before the browser times out.
Insert a Wait Node: After the AI Agent node, insert a Wait node set to a very short duration (e.g., 5-10 seconds). This forces the workflow to pause, allowing the AI to finish.
Immediate Form Ending: The final node remains the Show results (Form Ending) node.
Why this is risky:
Unreliable: If the AI takes 11 seconds, the form will still time out.
Scalability: If you get many submissions at once, the waiting workflows will consume resources and potentially slow down your entire n8n instance.
Our honest advice remains the Asynchronous Architecture (Fire-and-Forget), as it is the only way to guarantee a stable and reliable experience for your users, especially when dealing with the unpredictable latency of AI models.
Feel free to reach out if you have any follow-up questions.
with all due respect, this seems like a major gap in the product.
Let me rethink this.
So I do have an email node, that sends the AI response. Is it somehow possible to include a deep link or something to that mail?
So a flow like this
User submits idea > AI processes it > form simply says “thank you submitted” > waits for email > clicks on link in email > continues to work on idea based on AI feedback
This would decouple the AI response from the original form submission.
To make this work seamlessly, you should use a Unique ID to link the submission to the final result.
Step
Action
Best Practice
1. Submission
User submits the form.
Generate a $uuid (Unique ID) immediately.
2. Acknowledgement
Form shows: “Success! We’re processing your idea.”
Redirect or inform the user to check their email.
3. AI Processing
AI Agent runs in a separate workflow.
Store the result in a DB (Notion/Airtable) indexed by that Unique ID.
4. Deep Link
Send email with a link: https://your-n8n-webhook/results?id=UUID.
This link points to a Webhook Node or a Wait for Webhook event.
How to handle the “Deep Link” in n8n
The most robust way to do this is:
Workflow C (The Result Page ): Create a small workflow starting with a Webhook Node (GET method).
It takes the id from the URL, fetches the AI result from your database, and uses the Respond to Webhook node with “HTML” to render a clean page showing the feedback.
This completely decouples the “Wait” from the “Action,” giving your AI all the time it needs without ever locking the user’s browser.
Yes, that break between browser and email is normal and actually makes things more stable. You let the AI run in the background and only show the result when it’s ready, instead of making the user wait on an open page.
To display the page you just use the Respond to Webhook node. After the Webhook node reads the id from the URL and you load the result from your database, the Respond to Webhook returns HTML as the response.
That HTML you return is the webpage itself. The browser receives it and renders it like any normal page, no special HTML node needed.
I really appreciate the big help in this thread, and it is very insightful to learn about certain limitations in a good way before providing production-ready solutions or things that I think are production-ready.
One thing I noticed is when I’m using a public chat, I don’t seem to have that problem. Could that be the solution eventually?
