RAYAXIS

Blog

Laravel Queue Workers in Production: Retries, Timeouts, and Quiet Failures

January 14, 2026laravel · queues · horizon · devops

How we run Laravel queues in production so emails, imports, and webhooks fail loudly enough to fix — not silently.

All posts

Queues hide failures by design

That is useful until a webhook processor dies for a week and nobody notices. Production queues need the same seriousness as the HTTP app.

Settings we always define

  • Timeouts per job class — long imports should not share defaults with mail
  • Tries + backoff — distinguish transient network blips from poison messages
  • failed_jobs review cadence — someone owns the list
  • Idempotency — jobs that may run twice must not double-charge or double-email

Supervisor / systemd, not queue:work in tmux

Workers must restart on deploy and on crash. Document the number of processes relative to Redis/DB capacity.

Horizon when Redis is the backbone

For Redis queues, Horizon gives visibility that justifies itself the first time a backlog spikes at 2 a.m.

Alerting that is worth paying for

Alert on growing backlog age, repeated failures of the same job type, and worker heartbeats — not on every single exception email.

We wire this up when Rayaxis ships Laravel backends that send mail, process uploads, or talk to payment providers. Silent queues are expensive.

← Back to blog