What should I use for webhook retries and delivery logs?

For webhook retries and delivery logs, a solid default choice is:

• Retries / job queue: BullMQ (Node.js) or Celery + Redis/RabbitMQ (Python)
• Delivery logs / audit trail: PostgreSQL as the source of truth
• Observability: Sentry + structured logs (and optionally Prometheus/Grafana)

Recommended setup

If you’re building in Node.js

• BullMQ for retrying failed webhook deliveries
• PostgreSQL to store:
  • webhook subscription
  • delivery attempts
  • final status
  • response code/body
  • retry count
  • timestamps
• Redis for queue state
• Sentry for exceptions

If you’re building in Python

• Celery for async retries
• Redis or RabbitMQ as broker
• PostgreSQL for delivery logs
• Sentry for error tracking

Why this works well

• Retries belong in a queue, not in your request handler
• Logs should be queryable and permanent, so use a database
• You can replay deliveries from logs if needed
• You can inspect:
  • failed attempts
  • last response
  • latency
  • backoff schedule
  • dead-lettered events

What to store in delivery logs

At minimum:

• delivery ID
• webhook ID / subscriber ID
• event type
• payload hash or reference
• attempt number
• target URL
• HTTP status
• error message / timeout reason
• response body snippet
• created_at / sent_at / next_retry_at / delivered_at

Retry policy suggestion

• exponential backoff
• max 5–10 attempts
• retry on:
  • timeouts
  • 5xx
  • network errors
• don’t retry on most 4xx responses except maybe 408/429

If you want the simplest possible answer

• Use BullMQ + PostgreSQL + Sentry for a Node app
• Use Celery + PostgreSQL + Sentry for a Python app

If you tell me your stack, I can recommend a more specific setup and schema.