Troubleshooting Local LLM Automation Workflow Failures in n8n

6 min read · Updated Jul 17, 2026

Local LLM workflows in n8n break in five recurring ways: connection refused from a Docker networking mismatch, malformed JSON from a small model, responses truncated mid-sentence, the GPU running out of memory under load, and a workflow that quietly loops forever. Every one of these has a specific fix, and none of them are solved by "just use a bigger model."

Key takeaways

"Connection refused" almost always means n8n is looking for Ollama at localhost from inside its own Docker container, where localhost means the container itself.
Malformed JSON from small models is not random. It is fixable by pinning the schema in the system prompt and enabling Ollama’s JSON format mode.
Truncated output usually means you hit the default max token limit, not a model failure.
A GPU running out of memory under concurrent n8n executions needs a concurrency cap, not a smaller model.
Every local LLM node needs a maximum iteration count and a timeout. Without both, one bad response can hang a workflow indefinitely.

Failure 1: "connection refused" from the Ollama node

This is the failure almost everyone hits first, and it has nothing to do with Ollama itself. If n8n runs inside a Docker container and you point it at http://localhost:11434, that request never leaves the container. The container’s own loopback address is not your host machine.

yaml

services:
  ollama:
    image: ollama/ollama:latest
    ports:
      - "11434:11434"

  n8n:
    image: n8nio/n8n:latest
    environment:
      # correct: service name resolves inside the Compose network
      - OLLAMA_BASE_URL=http://ollama:11434
      # wrong: this resolves to the n8n container itself
      # - OLLAMA_BASE_URL=http://localhost:11434
    depends_on:
      - ollama

Fix: reference Ollama by its Docker service name, not localhost, when both run in the same Compose network.

If n8n runs on the host machine directly (no Docker) and Ollama also runs on the host, localhost:11434 is correct. The rule is simple once you know it: match the networking context, not the machine.

Close-up of an AI-assisted code debugging interface with error output highlighted

Failure 2: the model wraps JSON in friendly prose

A 7B or 8B model asked for JSON will often reply "Sure, here is the extracted data:" followed by the JSON you actually wanted. The next node in your workflow tries to parse that whole string and explodes. This is the single most common reason a local LLM workflow that worked in testing starts failing in production the moment real, messier documents arrive.

One Thursday night in September 2024 I had a support-ticket classifier running against a local Mistral 7B model. It had classified 800 tickets cleanly in staging. In production, ticket 34 contained a stray curly brace in the customer’s own message, the model got confused and replied with two sentences of apology plus a JSON blob, and the parser node threw an unhandled exception that took the whole branch down for six hours before anyone noticed the backlog. The fix was two lines in the system prompt and a JSON-mode flag I should have set from day one.

json

{
  "model": "llama3:8b",
  "format": "json",
  "options": { "temperature": 0.1 },
  "messages": [
    {
      "role": "system",
      "content": "Reply with a JSON object only. No prose, no code fences, no apology. If a field cannot be determined, use null. Never wrap the object in explanatory text."
    },
    { "role": "user", "content": "<<< input text >>>" }
  ]
}

Force JSON-only output and validate before anything downstream trusts it.

Failure 3: the response cuts off mid-sentence

If your extracted JSON is missing a closing brace, or a summary just stops halfway through a word, you have hit the model’s output token limit, not a bug in the model itself. Ollama and most local runtimes default to a modest number of output tokens unless you raise it explicitly.

bash

curl http://ollama:11434/api/generate -d '{
  "model": "llama3:8b",
  "prompt": "Summarise this document in full.",
  "options": {
    "num_predict": 2048
  }
}'

Raise the output token limit explicitly for longer extractions.

Failure 4: the GPU runs out of memory under real load

A single request works fine. Ten n8n executions firing in parallel crash the Ollama process with an out-of-memory error. This happens because n8n’s "Split in Batches" node, combined with a Loop, can fire more concurrent requests than your GPU has VRAM to serve. Each loaded model context takes real memory, and Ollama does not automatically queue overlapping requests for you at the defaults.

Cap the batch size in your Split in Batches node to 1 or 2 for GPU-bound local LLM calls, not the default of whatever fits the input array.
Set OLLAMA_NUM_PARALLEL=1 if you are on a single consumer GPU. Multiple parallel model instances on 12GB of VRAM is how you get a crash instead of a queue.
Watch nvidia-smi while a real batch runs once, before assuming any of the above numbers are right for your card.

Failure 5: the workflow silently loops forever

This is the expensive one, and it is not really about the LLM at all. A self-correcting or retry pattern that checks "did the model return valid output, if not try again" needs a hard iteration cap. Without one, an upstream schema change or a persistently confused model will retry indefinitely, and on local hardware that means your GPU pins at 100% until someone notices the fan noise.

I think most local LLM debugging guides focus too much on the model and not enough on the plumbing around it. A local model is not less reliable than a cloud API, it just fails in more visible, more physical ways: a full GPU, a wrong hostname, a silent timeout. Debug the plumbing first, the prompt second.

“None of these five failures are exotic. They are the same five things breaking every local LLM workflow on the internet right now, quietly, one Docker network setting at a time.”

Frequently asked questions

Why does n8n say "connection refused" when calling Ollama?

Almost always because n8n runs inside a Docker container and is pointed at localhost, which resolves to the container itself, not the host machine or a sibling container. Use the Docker service name (e.g. http://ollama:11434) instead.

How do I stop a local LLM from adding extra text around JSON output?

Set Ollama’s "format": "json" flag, pin the exact schema in the system prompt, and explicitly instruct the model to return the object with no surrounding prose. Validate the output in a Code node regardless, since small models occasionally ignore instructions.

Why does my local LLM response cut off mid-sentence?

You have hit the default output token limit. Raise num_predict in the Ollama request options to a value large enough for your expected output length, typically 1024 to 2048 for summaries or multi-field extractions.

Why does Ollama crash when n8n runs multiple executions at once?

A single consumer GPU usually cannot hold multiple concurrent model contexts in VRAM. Cap your Split in Batches node to 1 or 2 items and set OLLAMA_NUM_PARALLEL=1 so requests queue instead of competing for memory.

How do I stop a self-correcting workflow from looping forever?

Add an explicit iteration counter in a Set node and check it before every retry branch, capping at 2 to 3 attempts. Route anything past the cap to a human-review branch instead of letting the loop retry indefinitely.