Stop Retrying a Dead Provider: The Cooldown Rule for n8n Fallback Chains

Description and use

In n8n, a fallback chain keeps retrying a dead provider, wasting cost and time. Adding a cooldown rule skips the provider after consecutive failures, reducing wasted requests and speeding the queue.

Problem

When a provider in an n8n fallback chain goes down, the chain keeps retrying it for every job, wasting cost and time.

Outcome

Implementing a cooldown rule reduces wasted requests from a dead provider from 50 to 3 per job, saving cost and speeding the queue.

Workflow

• Honor Retry-After header and add jitter to backoff
• Track consecutive failures per provider and set a cooldown_until timestamp after N failures
• Use a Code node to skip providers in cooldown without probing
• Reset consecutive_failures on success, re-arm cooldown on subsequent failures
• Validate fallback output against schema and brief to avoid silent degradation

Evidence

When a provider rate-limits you, it often tells you how long to wait in a Retry-After header. Use it — it's the provider telling you the cheapest wait, and ignoring it is how a rate limit becomes a ban.

Source

After N consecutive failures from one provider — I use three — mark it cooled-down for a window (ten minutes is my default) and skip it entirely.

Source

Mock a provider that always 500s, then run ten jobs through the chain and count requests at the mock. Without cooldown: fifty requests, ten per job, all wasted. With cooldown: three requests for the first job, then zero for the next nine until the window expires.

Source