How do I set retries without trashing my quota or the source API?
Default retry settings are often 'every minute, 5x'. Too aggressive for some APIs, too weak for others. Exponential backoff plus dead-letter is the robust setup.
Try this first
- 1Per error type: 5xx and timeouts are retryable, 4xx (except 429) is not (input error, retry won't help).
- 2Set exponential backoff: 30s, 1m, 5m, 30m, then dead-letter. That gives transient outages room without hammering the source API.
- 3On 429 (rate limit): respect the Retry-After header, not your own schedule. That is what the source declares safe.
- 4After last retry: write the payload to a dead-letter queue (DB table or Make Data Store or n8n table) plus error context. Don't let it disappear.
- 5Daily review on DLQ: manually re-submit or permanently reject. A DLQ no one looks at is not a DLQ.
When to bring us in
Need a DLQ that spans multiple flows and tools, we can set up the table and re-process flow.
See also
- n8n: self-host or cloud?Self-hosted is cheaper at volume and keeps data local. Cloud removes ops burden.
- Zapier or Make: which fits better?Zapier is straight-line; Make handles complex flows with routers and iterators for less money.
- Power Automate Cloud or Desktop: which to use?Cloud for SaaS integrations and triggers. Desktop for RPA against legacy Windows apps without APIs.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.