n8n Automation Hub
A rate limit that told me exactly what to do, and got ignored anyway
Groq's chat completions API doesn't just reject an over-limit request — its error body says precisely how long the caller should wait: Please try again in 1.425s. That's about as helpful as an API error gets. The problem wasn't that the information wasn't available; it's that the node calling Groq had nothing configured to act on it. One HTTP 429 and the execution ended there.
The node is Groq LLM - Pick Best Moments in WF-CLIP-02 Clip Processor, part of the Success Bites AI clipping pipeline. It sends a podcast or long-form video transcript to Groq's openai/gpt-oss-120b model and asks it to identify the highest-potential moments to cut into short clips — a single sizeable request per source video, not a high-frequency call. Even at low frequency, a request that happens to land close in time to another one on the same API key can push the rolling tokens-per-minute count over Groq's limit for that tier.
Why this one is easy to miss until it happens
This node isn't looping or firing repeatedly — it's one HTTP call per video, run on a schedule. That made the rate limit easy to not think about: nothing about the workflow's normal operation suggests it's anywhere near a request-volume ceiling. The 429 only shows up when this workflow's run happens to overlap with token usage from something else hitting the same Groq account close enough in time, which is intermittent and not reproducible on demand.
Groq's response used a tier called on_demand with an 8000 TPM limit — well below what a bigger paid tier would allow. The fix here isn't upgrading the tier or reducing the prompt size; it's making the one call this node makes resilient to landing in a bad second, the same way a transient Google API 503 gets handled elsewhere on this instance.
The fix
The node had no retryOnFail setting at all before this check — confirmed by reading its live configuration, not assumed from the workflow running fine most of the time. It was updated via the n8n API to retryOnFail: true, maxTries: 3, waitBetweenTries: 3000. Three seconds comfortably clears the 1.425-second wait Groq's own error reported for this specific rejection, with two more attempts as headroom if a retry lands in another busy window. This didn't touch the request body, the model, or the prompt — the LLM call itself is unchanged; only what happens after a 429 response changed.
What confirmed it
The node's configuration was read back fresh from the n8n API after the update: retryOnFail: true, maxTries: 3, waitBetweenTries: 3000 present on Groq LLM - Pick Best Moments. There's no way to force Groq to return a real 429 on demand to test the retry path end-to-end, so this stands on the setting being persisted correctly and n8n's documented retry behavior, the same standard used for the other retry fixes on this site. The workflow was re-fetched and is still active: true.
Groq's limits, and which one a 429 is about
Groq applies several limits per model and per organization, and the error body names the one you hit:
| Limit | Abbreviation | What a retry does |
|---|---|---|
| Requests per minute | RPM | Usually clears within seconds |
| Tokens per minute | TPM | Usually clears within seconds, as in this article |
| Requests per day | RPD | Does not help until the daily window frees up |
| Tokens per day | TPD | Does not help: retries seconds apart all fail |
The difference matters for the fix. A retry three seconds later solves a per-minute limit. For a daily limit, the error says something like "try again in 9 minutes" or longer, and the useful options are a different model with its own quota, a smaller prompt, or a paid tier. One of my daily publishers now falls back to a smaller model through the HTTP node's error output when the main model's daily token budget is used up by other workflows on the same account.
Reading the limits before you hit them
Groq's responses include rate-limit headers, among them the remaining requests and tokens in the current windows, and a retry-after header on a 429. In an HTTP Request node, turning on "Include Response Headers and Status" in the options makes them visible in the output. Logging the remaining-tokens header for a few days shows how close a workflow runs to the limit, before a 429 tells you.
Where retries are not enough
- Many workflows share one key. All of them draw from the same per-model budget. Spreading their schedules apart helps more than more retries.
- One request is larger than the TPM limit. No amount of waiting helps. The input has to be split, as described in the article on splitting one LLM call into three.
- Retries multiply load. Three tries on every node in a burst can make a busy minute worse. Keep maxTries low and the wait above the time the error asks for.
Frequently asked questions
How do I handle a Groq 429 error in n8n?
For per-minute limits, enable Retry On Fail on the HTTP Request node, for example 3 tries with 3,000 ms between them. That clears the short waits Groq reports for TPM and RPM limits.
Why do retries not help with a tokens-per-day limit?
The daily window frees up over hours, not seconds. Use a different model with its own quota, reduce token usage, or upgrade the account tier.
Do all workflows on one Groq key share the limit?
Yes. Limits apply to the organization and model, so several workflows using the same model draw from one budget.
Can I see how close I am to the limit?
Yes. Groq returns rate-limit headers on each response. Enable response headers in the HTTP Request node options to log them.