The Retry Budget: Why My n8n LLM Workflows Retry Exactly Once, Then Page a Human
Description and use
The article explains how to set a retry budget for LLM workflows in n8n to save tokens and improve reliability by classifying errors into three groups and applying different retry strategies.
Problem
When an LLM completion fails validation, it is unclear whether to retry automatically or send it to human review, risking unnecessary cost and inefficiency.
Outcome
Implemented a retry budget that reduces unnecessary prompt costs, improves reliability, and provides clear escalation to human review.
Workflow
- Classify error type and count attempts in a Code node
- If transient and attempts ≤3, set action to retry_backoff
- If repairable and first attempt, set action to retry_with_feedback
- If deterministic or repeated repairable failure, set action to review
- Route based on action field to retry or review queue
Evidence
Every LLM failure in my workflows falls into one of three buckets, and each bucket gets a different response:
I logged 200 repairable failures over a month. First feedback-retry success rate: 71%. Second retry on the remaining 29%: 9% of those.
- Record date: 2026-10-14T02:40:59.544Z