The best n8n fix I found this month was boring: lower your agent concurrency settings before touching the prompt

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:

• OpenAI-compatible requests returned 429
• a couple of tool calls fired twice
• one branch retried enough times to make the whole run look random
• outputs got inconsistent enough that it felt like GPT had suddenly gotten worse

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.

The real failure mode: collision, not intelligence

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:

• provider rate limits
• queue behavior
• retry policy
• tool idempotency
• downstream API stability
• whether your workflow can survive burst traffic without tripping over itself

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:

1. A burst of webhook executions arrived
2. Requests slowed down
3. Some calls started failing with 429
4. Retries piled onto the original burst
5. Duplicate tool calls made outputs look inconsistent
6. Everyone blamed the prompt

The prompt was innocent.

What I tried first that did not help

I did the usual panicked engineer moves:

• tightened the prompt
• changed model settings
• considered swapping endpoints
• looked at retry behavior from the wrong angle

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:

• failures clustered around bursts
• clean runs happened when traffic was spaced out
• the exact same workflow looked stable when only a few executions were in flight

That was the moment I stopped thinking "GPT got worse" and started thinking "my workflow is stampeding the LLM stack."

The first setting I would change in n8n

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:

• n8n stops letting every production execution run immediately
• extra executions get queued
• your LLM requests hit providers in a more controlled pattern
• retries are less likely to amplify a temporary spike

It does not make a burst magically disappear.

It does make the system behave like an adult.

Why this works better than prompt surgery

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:

• rewriting the prompt won't reduce concurrency
• switching from GPT-5.4 to Claude Opus 4.6 won't remove a rate-limit bottleneck
• adding retries can make the whole thing worse

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.

A simple way to reason about it

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, 429s 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.

What changed after setting the cap

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:

• fewer 429 failures
• fewer duplicate tool calls
• fewer fake "model quality" investigations
• more runs completing on the first attempt

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."

If you run agents 24/7, this matters more than people admit

This is not just an n8n thing.

If you're running always-on automations in:

• n8n
• Make
• Zapier
• OpenClaw
• custom workers
• agent frameworks with OpenAI-compatible clients

then load-related reliability problems become throughput problems fast.

Every retry storm:

• eats capacity
• increases latency
• creates duplicate side effects
• makes incidents harder to debug
• turns one burst into a bigger burst

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:

• unpredictable traffic
• retry cascades
• token burn from failures
• engineers getting dragged into cost monitoring

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.

A practical debugging checklist

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

My current default stance

If an n8n agent workflow suddenly gets flaky, I now assume this order of operations:

1. inspect timing
2. inspect concurrency
3. inspect retries
4. inspect duplicate side effects
5. only then inspect the prompt

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.