I spent an embarrassing amount of time blaming the model for a problem that was clearly my own fault.
A webhook burst hit one of my n8n flows. Around 20+ executions landed almost at once. Then the workflow started acting cursed:
429
My first instinct was the same instinct I see all over AI workflow Twitter and Reddit now:
"The model is flaky."
It wasn't.
The fix that actually worked was much more boring:
Lower concurrency before you touch the prompt.
For n8n, the setting that mattered was:
N8N_CONCURRENCY_PRODUCTION_LIMIT=20
That one change did more for reliability than prompt edits, model swapping, or retry tweaking.
When a bunch of webhook-triggered executions all slam the same LLM path at once, you're not really testing GPT-5.4 or Claude Opus 4.6 or Grok 4.20.
You're testing all of this at the same time:
That distinction matters.
A lot of what people call "model instability" is really just queueing chaos with better branding.
Here's the pattern I saw:
The prompt was innocent.
I did the usual panicked engineer moves:
None of it fixed the core issue.
Because this was not semantic failure. It was concurrency collision.
The clue was obvious once I stopped reading outputs and started looking at timing:
That was the moment I stopped thinking "GPT got worse" and started thinking "my workflow is stampeding the LLM stack."
If you're running production webhook/trigger flows in n8n, I would start with a concurrency cap.
Example with Docker Compose:
services:
n8n:
image: n8nio/n8n:latest
environment:
- N8N_CONCURRENCY_PRODUCTION_LIMIT=20
Or with a plain environment variable:
export N8N_CONCURRENCY_PRODUCTION_LIMIT=20
If you're deploying with something like Render, Railway, Fly.io, or Kubernetes, set the same env var in your runtime config.
What this does in practice:
It does not make a burst magically disappear.
It does make the system behave like an adult.
Prompt edits can improve output quality.
They do absolutely nothing for a request pileup.
If the problem is too many executions hitting the same OpenAI-compatible endpoint at once, then:
Retries are especially dangerous here.
A short-lived 429 should be a small bump. But if 20 executions all retry aggressively at the same time, you've turned a brief provider limit into a self-inflicted traffic storm.
Think of your workflow like this:
Webhook burst
-> n8n execution fanout
-> LLM call
-> tool call
-> retry logic
-> downstream side effects
If the burst is uncontrolled, every weak point gets stressed at once.
Now compare the two modes:
| Situation | What usually happens |
|---|---|
| No concurrency cap | Burst traffic hits the LLM path immediately, 429 s appear, retries stack, tool calls duplicate |
| Concurrency cap enabled | Extra runs queue, LLM traffic smooths out, fewer retries fire, behavior gets predictable |
This is why I think the common advice is backwards.
When an agent workflow starts acting haunted under load, the first move should be traffic shaping, not prompt tweaking.
The improvement was not dramatic in a flashy demo sense.
It was better than that.
It was predictable.
After setting N8N_CONCURRENCY_PRODUCTION_LIMIT=20, I saw:
That's the kind of win I actually care about in production.
Not "the benchmark went up."
More like: "I can stop babysitting this workflow."
This is not just an n8n thing.
If you're running always-on automations in:
then load-related reliability problems become throughput problems fast.
Every retry storm:
And if you're paying per token, it can also turn a bad hour into a stupid bill.
That's one reason I think flat-rate inference is underrated for automation workloads.
When agents are running 24/7, the pain is not just model cost. It's the combination of:
With Standard Compute, the appeal is not only that it's an OpenAI-compatible API. It's that agent-heavy workloads can run on a predictable monthly cost instead of turning every burst into billing anxiety.
If your automations live on constant LLM calls, "unlimited compute" is a lot more useful than people think — especially when the alternative is watching retries multiply your bill.
Before you rewrite your prompt, I would check these in order:
1. Did failures cluster around burst traffic?
2. Are you seeing 429s or timeout spikes?
3. Are retries amplifying the problem?
4. Are tools idempotent, or can duplicates cause damage?
5. Is concurrency capped at the workflow/runtime level?
6. Only then: is the prompt actually the problem?
If you want the short version:
Weird outputs + burst traffic != model got worse
Weird outputs + burst traffic often == concurrency problem
If an n8n agent workflow suddenly gets flaky, I now assume this order of operations:
That order has saved me a lot of wasted time.
Prompt surgery is seductive because it feels like you're fixing the AI part.
But a lot of production AI bugs are not really AI bugs.
They're systems bugs wearing an LLM costume.
And yes, the best fix I found this month was boring.
Still the right fix.