Laravel Horizon em produção — dimensionar workers, sobreviver ao Redis, e a estratégia de retry
6 de maio de 2026 · 1 min de leitura · por Sudhanshu K.
O Horizon torna as filas do Laravel legíveis. O dashboard é ótimo, o modelo de supervisor é de fato útil, e a história de failover está correta. O que ele não faz é decidir o dimensionamento dos seus workers, a estratégia de isolamento de filas, ou a política de retry — esses ainda são problemas seus, e os defaults são conservadores de jeitos que escondem problemas reais em produção.
Esta é a config do Horizon que entregamos em cada instalação Laravel gerenciada que faz trabalho relevante em background.
Uma config de supervisor em produção
'environments' => [
'production' => [
'supervisor-default' => [
'connection' => 'redis',
'queue' => ['critical', 'default'],
'balance' => 'auto',
'minProcesses' => 4,
'maxProcesses' => 20,
'balanceMaxShift' => 2,
'balanceCooldown' => 3,
'tries' => 5,
'timeout' => 60,
],
'supervisor-long' => [
'connection' => 'redis',
'queue' => ['long-running'],
'balance' => 'simple',
'maxProcesses' => 4,
'timeout' => 600,
],
],
],Dois supervisors: um para jobs curtos de alta prioridade (balance auto, mais workers), um para jobs batch long-running (workers fixos, timeout maior, sem balanceamento). Pôr os dois no mesmo supervisor com o mesmo timeout é a má-configuração do Horizon mais comum que vemos.
O artigo completo cobre:
- Isolamento de filas — por que «default» não deveria ser a única fila
balance: autovsbalance: simplevsbalance: false- Persistência do Redis (AOF every-second) e o que acontece quando o Redis reinicia
- O helper de retry-backoff e idempotência em handlers de webhooks entrantes
- Detecção de memory leak —
--memory=128e o padrão de reciclagem de worker - Higiene do dashboard de failed jobs e os alertas que ligamos na tabela failed_jobs
Entregamos essa config do Horizon em cada deploy Laravel gerenciado.
Full article available
Read the full article