Two items. One failure.
Four requests.

1. The setting that changes the result

With Retry On Fail enabled, our two-item HTTP Request node sent four requests after a single 503. Its final output still contained two successful items. Request-level assertions caught the extra calls.

The HTTP node’s Items per Batch option controls request scheduling inside that node. In this experiment, a batch size of 1 kept the two-item retry boundary intact. A Loop Over Items node with batch size 1 gave each HTTP execution a single item.

n8n’s node-settings documentation describes retrying the node after failure. The HTTP batching settings set request batch size and interval. The table records how those settings interacted in the pinned runtime.

2. Give each retry one item

Download the annotated n8n template ↗ · Import from File, then configure the Render test endpoint. Canvas notes include the exact response sequence and setup.

1. Place Loop Over Items before the HTTP Request node. Set Batch Size to 1.
2. Connect its loop output to HTTP Request. Keep Retry On Fail enabled on HTTP Request.
3. Connect the HTTP output back to Loop Over Items. Use the loop’s done output for the combined results.

In the recorded loop case, item 42 completed its two attempts before item 43 ran once. Both final render IDs appeared at Done. The official Loop Over Items documentation explains its per-iteration batch and combined done output.

This pattern processes the items serially. Choose it where item-level retry isolation is worth the throughput trade-off; use the API’s documented backoff and rate limits for the wait settings.

3. Give the write a stable identity

The failing item still makes two attempts. For APIs that create invoices, jobs, or other business records, design for the server accepting a write and its response getting lost.

Use the API’s supported idempotency mechanism. Build the key from a persistent business operation—such as invoice:tenant-7:inv-42:revision-3—and reuse it with the same payload across retries and redelivery. A new intended operation gets its own key.

The server’s contract determines key retention, payload-conflict handling, and duplicate responses. For a backend you own, persist the operation identity and business result atomically. Our Document Approval Gate sample demonstrates a frozen approval revision, outbox delivery, and a synthetic ERP retry after a lost response.

4. Run the three cases

The MIT-licensed workflows and fixtures run in n8n-check. Git and Docker give you the pinned n8n runtime and a local HTTP mock:

git clone --branch v0.1.1 https://github.com/blucca/n8n-check.git
cd n8n-check
docker build -t n8n-check .

for mode in direct http-batching loop; do
  docker run --rm --network none \
    -v "$PWD:/work" n8n-check \
    "examples/retry-isolation/$mode.json" \
    "examples/retry-isolation/$mode-case.json" \
    --out "/work/results/$mode" || exit "$?"
done

On Linux, add --user "$(id -u):$(id -g)" when your user ID differs from the image’s default 1000. Windows users can use WSL. The repository README also covers an existing local n8n installation.

Each case asserts request counts, every request body, and final outputs. Read results/<mode>/report.json for the captured requests and checks, or junit.xml for CI. Compare against the recorded results.

For your own release, start with two distinguishable items and one controlled transient failure. Agree the expected request count before running it. Then add your provider’s duplicate-write and retry-exhaustion cases.

Trying it? Share your version and observed counts. A small, synthetic workflow makes a useful next fixture.