n8n queue mode and Sume webhooks: the 10-second budget

A Sume webhook delivery attempt times out after 10 seconds, and Sume tries up to 10 times, 30 seconds apart by default, so a receiver should store the event and return a 2xx right away. The n8n releases page lists n8n@2.42.2 (Oct 1, 2026) with a fix for queued execution handling in the Bull job system, which is a good moment to re-check where your webhook work actually runs.

Sume delivery behavior

Why queue mode raises the question

The release note says only that a fix landed for queued execution handling. It does not say how long a webhook-triggered run waits before it starts, so do not assume. What matters for Sume is simple: if a slow endpoint burns the 10-second budget, Sume retries, and you may process the same event twice.

What to do in the receiver

• Verify x-sume-webhook-signature over <timestamp>.<raw_body> before trusting the body.
• Store the event keyed by job_id, return 2xx, and do the heavy work after the response.
• Make the work idempotent so a retry or a Redeliver is harmless.
• Keep status_url polling as a backup for events that never arrive.

Redeliver and testing

The dashboard has Send test, which posts a dummy webhook.test payload to a URL you type, and Redeliver, which re-sends a real job's terminal event with a fresh timestamp and signature. Redeliver does not consume one of the automatic 10 attempts. Use Send test to measure how fast your n8n endpoint answers before you rely on it.