Bulk-retrying failed n8n executions after an upstream outage

A third-party API provider (OpenAI, a CRM, an SMS gateway) goes down for twenty minutes on a Tuesday morning, and a whole slice of your n8n instance turns red: fifty, two hundred, sometimes several thousand executions finish in error by the time the service comes back. Clicking "Retry" one execution at a time works for three of them, not three hundred. Here's how to identify, retry, and secure a bulk catch-up without turning an upstream outage into a self-inflicted one.

The problem: one outside failure multiplies into many, not one

A workflow that calls a third-party API on every run — a misconfigured HTTP Request node changes nothing here — mechanically inherits that API's availability. A twenty-minute outage at a provider doesn't fail one workflow, it fails every execution that lands inside that window: email sorting from the Inbox AI Pack, reply generation from the RAG Assistant Pack, report delivery from the Compliance & Audit Pack — everything depending on that API piles up in the Executions tab with an "Error" status, waiting to be dealt with.

The UI's Retry button: great for one, not for volume

From a failed execution's detail view, n8n offers a "Retry" button with a simple choice: replay the workflow exactly as it was at the time of failure, or load the currently saved version — useful when the original problem actually came from a bug in the workflow, fixed since. It's the right tool for a single execution. But the UI has no multi-select and no "retry everything in error" button: past about a dozen executions, clicking one by one becomes the real bottleneck, not the outage itself.

The API endpoint: POST /executions/{id}/retry

n8n exposes the same mechanism through its public REST API: POST /api/v1/executions/{id}/retry, with a loadWorkflow boolean in the request body controlling which of the two versions gets replayed. Paired with GET /api/v1/executions?status=error, which lists failed executions (also filterable by workflowId, with cursor-based pagination for larger volumes), these two endpoints give you everything needed to script a catch-up: list, then retry each ID you pulled.

Don't retry everything at once: the retry-storm risk

Once the script is written, the temptation is to loop over all five hundred IDs without waiting. That's exactly the instinct to resist. The problem of massive, synchronous retries after an incident is well documented in the large-scale distributed-systems literature: a landmark paper by Jeffrey Dean and Luiz André Barroso, Google engineers, published in 2013 in Communications of the ACM, describes how uncontrolled retries after a slowdown or partial outage can create a feedback loop that piles more load onto a service that just came back, instead of simply catching up (Dean & Barroso, 2013, CACM). Applied to n8n: firing two thousand retries at once toward an API that only just recovered risks taking it back down, or tripping its own rate limiting — regenerating a fresh wave of failures.

A batched catch-up script, with pauses

The approach that holds up in practice stays simple:

1. List the failed executions for the relevant window via GET /executions?status=error&workflowId=..., filtered to the outage's time range.
2. Chunk the list into batches of 10 to 20 IDs.
3. Retry each batch via POST /executions/{id}/retry, with a pause of a few seconds between each individual call and between batches.
4. Check the new status before moving to the next batch, so you can stop the script if the upstream API dips again.

An n8n workflow scheduled on a timer can run this script itself — orchestrating its own catch-up with a Code node and a controlled loop, rather than an external script launched by hand. On an instance running queue mode, the same pacing also avoids overwhelming the workers just as they're getting back to processing the normal queue.

Securing the API key used for the catch-up

A bulk-retry script needs an API key with the workflow:execute scope — not just workflow:read. This was actually the subject of a 2026 security fix at n8n: the retry endpoint originally checked read-level access rather than execute-level access, meaning an API key meant purely for read-only monitoring could still trigger retries. One more reason to keep your instance current and apply least-privilege credentials: a dedicated, time-limited catch-up key rather than reusing a broad-scope admin key.

The real risk is the duplicate, not the failure

Retrying an execution that failed before any write is harmless. The problem shows up when a workflow writes to a database, sends an email, or charges an invoice before failing on a later step: a retry replays the workflow from the start, potentially including that already-completed action. The fix isn't hoping that case never happens, it's making sensitive steps idempotent — an existence check before an insert, a unique key at the database level — so a redundant retry fails quietly on the second attempt instead of duplicating the side effect.

A practical case: one OpenAI outage hitting two packs at once

An instance running both the Inbox AI Pack (email classification) and the RAG Assistant Pack (documentation chatbot) shares the same dependency on the OpenAI API. A twenty-minute outage at that provider fails both workflow families at the same time. The catch-up script should then filter by workflowId to handle the most time-sensitive executions first — urgent email sorting before the daily digest, for instance — before draining the queue of less critical ones.

Pitfalls to avoid

• Retrying without filtering by date: too broad a script can also re-attempt old failures unrelated to today's outage, ones a manual fix might already be in progress for.
• Ignoring failures that aren't from the outage: a bad payload or a credentials error produces the same "Error" status as an upstream outage — retrying will never fix those, no matter how many attempts.
• Forgetting to clean up processed executions: without regular execution history cleanup, the executions table grows needlessly after a spike of thousands of failures followed by retries.
• Only noticing the outage once it's produced hundreds of failures: active instance monitoring often catches the degradation earlier and lets you tune the pacing before the backlog piles up.

In summary

The Retry button in n8n's UI is enough for a handful of executions; beyond that, the REST API (GET /executions?status=error then POST /executions/{id}/retry) becomes the only reasonable path, provided you batch it so an already-resolved upstream outage doesn't turn into a fresh wave of overload. Combined with idempotent steps and a tightly scoped API key, this turns a third-party incident into a few minutes of scripted catch-up — rather than an afternoon of one-by-one clicking, whether it's the Inbox AI, RAG Assistant, or Compliance & Audit pack on the line.