I Stopped Scheduling My n8n Workflows on the Hour — My 429s Disappeared

Description and use

n8n workflows scheduled at the exact hour caused 429 errors due to API rate limits. Staggering schedules to non‑round minutes, adding jitter, and configuring retries eliminated the issue.

Problem

Multiple n8n workflows scheduled at the exact hour caused 429 Too Many Requests errors due to API rate limiting.

Outcome

Zero 429 errors and no manual re‑runs after two weeks; manual re‑run time dropped from ~20 minutes per week to none.

Workflow

• 1. Identify workflows scheduled at :00 via n8n execution list.
• 2. Move each schedule to a non‑round minute (e.g., 09:07, 09:23, 09:41).
• 3. Add a Wait node with random delay 0–90s at the start of bursty workflows.
• 4. Configure HTTP nodes to retry on 429 with exponential backoff (2s → 8s → 32s) and max three retries.

Evidence

Three workflows, one shared API key, all calling the same LLM endpoint at the top of the hour.

Source

The first one through got its tokens. The second one squeaked by. The third ate the rate limit.

Source

Level 1: stagger by hand (five minutes of work). I moved the three schedules to 09:07, 09:23, and 09:41 in the n8n UI.

Source

Level 2: jitter for anything bursty. I added a small Wait node at the head with a random delay of 0–90 seconds.

Source

Before: ~6–10 429 rejections per week across the three workflows, each one a dead-letter entry I had to manually re-run. After two weeks of staggered schedules: zero.

Source