Suggesting adding a retry mechanism for webhook-based triggers

Feature Requests
1

My use case:

I use webhook triggers in workflows that depend on real-time communication (e.g., receiving messages from Telegram or Stripe events). If the n8n instance is restarting or momentarily overloaded, some webhook requests get dropped, and the workflow never runs. This creates data loss and unreliable automation.

I think it would be beneficial to add this because:

It would make webhook-based workflows more fault-tolerant and reliable, especially in self-hosted environments. This is important for users who rely on n8n in production and can’t afford to lose incoming webhook data due to short outages or restarts.

Any resources to support this?

  • Telegram Bot API – Webhook Retry Behavior
  • Stripe Webhooks – Retry Logic
  • Some external tools like Nginx or message queues can do this manually, but it would be much more powerful and user-friendly if built into n8n directly.

Are you willing to work on this?

Not at the moment, but happy to test and give feedback if this gets added.Preformatted text

2

Yeah, this isn’t really an n8n thing specifically — any webhook receiver is going to drop requests if it’s down or overloaded, since retry behavior is entirely up to the sender. Stripe retries pretty aggressively, but a lot of other services just give up after one try. So “n8n was down for 90 seconds during a deploy” quietly turns into “that event just never happened.”

Adding retry to the webhook trigger node wouldn’t fully fix it either, honestly — n8n still needs to be up to even receive the retry.

What actually works is putting something in front of n8n that takes the webhook right away, then forwards it to your n8n URL with backoff, and a dead-letter queue if it still can’t get through after a few tries. That way a restart just delays things instead of losing the event completely.

You could build this yourself pretty easily — just a small queue + worker with jittered backoff retries. Or there are hosted services that already do this — I actually built one for this exact problem (Jitterflow, there’s an n8n node too), but honestly any retry+DLQ relay in front of your trigger would work.

Also worth checking what your provider’s own retry policy already covers — Stripe documents theirs, for example, so you might already be covered depending on what’s calling you.