Hoe stel ik retries in zonder dat ik mijn quota of de bron-API in de soep ram?
Standaard retry-instellingen zijn vaak 'elke minuut, 5x'. Dat is te agressief voor sommige API's en te zwak voor andere. Exponential backoff plus dead-letter is de robuuste opzet.
Probeer dit eerst zelf
- 1Bepaal per fouttype: 5xx en timeouts retry-baar, 4xx (behalve 429) niet retry-baar (input-fout, retry helpt niet).
- 2Stel exponential backoff in: 30s, 1m, 5m, 30m, dan dead-letter. Dat geeft tijdelijke storingen ruimte zonder de bron-API stuk te beuken.
- 3Bij 429 (rate limit): respecteer de Retry-After header, niet je eigen schema. Dat is wat de bron als veilig opgeeft.
- 4Na de laatste retry: schrijf de payload in een dead-letter-queue (DB-tabel of Make Data Store of n8n table) plus de fout-context. Niet in de void laten verdwijnen.
- 5Dagelijkse review op de DLQ: handmatig opnieuw aanbieden of permanent afkeuren. Een DLQ die niemand bekijkt is geen DLQ.
Wanneer ons inschakelen
Heb je een DLQ nodig die over meerdere flows en tools heen werkt, dan kunnen we de tabel en re-process-flow voor je opzetten.
Zie ook
- n8n: zelf hosten of cloud-versie nemen?Self-hosted is goedkoper bij volume en geeft data-controle. Cloud spaart je de ops weg.
- Zapier of Make: welke past beter?Zapier is rechttoe-rechtaan, Make doet complexere flows met routers en iterators voor minder geld.
- Power Automate Cloud of Desktop: wat moet ik nemen?Cloud voor SaaS-koppelingen en triggers. Desktop voor RPA op een Windows-machine met legacy-apps.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.