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.