Laravel Horizon Setup Guide: Monitor Redis Queues Like a Pro

This practical guide walks through a production-grade Laravel Horizon setup and operations plan. We'll cover installation, configuration, supervisors, queue balancing, alerting, observability and runbook ideas so teams can manage Redis-backed jobs with confidence.

Note: examples assume Redis as the queue driver and a modern Laravel release.

Why Horizon and Redis

Laravel Horizon is the officially supported dashboard and process manager to monitor Redis queues. It makes it easy to visualize queue throughput, failed jobs, and supervisors, but running Horizon reliably in production requires decisions: how many supervisors, how to distribute workers across queues, how to alert on failures, and how to tune Redis.

This guide repeatedly references practical patterns for laravel horizon setup redis queues to help you move from PoC to production.

Installation and basic configuration

1. Require Horizon and configure queue driver

• composer require laravel/horizon
• Set QUEUE_CONNECTION=redis in .env
• Publish Horizon config: php artisan vendor:publish --provider="Laravel\Horizon\HorizonServiceProvider"

2. Configure config/horizon.php

• Define environments, supervisors, and queue mapping.
• Example supervisor block (simplified):

'supervisors' => [
  'critical' => [
    'connection' => 'redis',
    'queue' => ['high', 'default'],
    'balance' => 'simple',
    'processes' => 10,
    'tries' => 3,
  ],
],

3. Redis tuning basics

• Use persistence settings that suit your SLA (AOF vs RDB). For queues, AOF may add durability at the cost of latency.
• Make worker scripts idempotent and short-running where possible.

Supervisors, balancing and worker sizing

Supervisor design is the most important operational decision.

• One supervisor per job-type or queue group keeps isolation (e.g., image-processing, email, notifications).
• Use process isolation when jobs are memory-heavy.
• Choose a balance strategy:
  • simple: equal distribution of processes among queues
  • auto: Horizon shifts workers to busy queues
  • false: no balancing

Sizing rules-of-thumb:

• CPU-bound: fewer processes, larger instance CPU
• I/O-bound: more processes per CPU
• Memory-bound: cap processes to avoid swapping

Comparison: balancing strategies at a glance

Below is a short comparison to help pick the right strategy.

Alerts and monitoring

Good monitoring uses both Horizon metrics and external alerting.

• Monitor failed_jobs table and Horizon failed job metrics

• Alert on:

  • Queue backlog over threshold (jobs/minute)
  • Repeated job failure spikes
  • Horizon process down
  • Redis latency or slow commands

• Integrate with PagerDuty, Opsgenie, or Slack for notifications.

Example alert rules:

• If a queue has > 500 waiting jobs for 5 minutes, page an engineer.
• If job failure rate increases by 3x over baseline for 10 minutes, trigger a high-priority incident.

Use Horizon's metrics (Prometheus exporters) or push Horizon telemetry into your APM.

Dashboards and observability

Build dashboards that show:

• Jobs processed per minute per queue
• Average job runtime and P95/P99
• Current queue length (pending jobs)
• Number of active workers per supervisor
• Failed jobs and retry rates

Use Grafana + Prometheus or your APM. Use Horizon's published metrics endpoint or integrate with Laravel Telescope for local debugging.

External references for observability and web performance:

• Google Search Central
• Google Lighthouse
• Mozilla MDN Web Docs
• OWASP
• NIST Cybersecurity Framework

Deployment and process management

• Run Horizon as a supervised system process (systemd, supervisord, or a process manager from your PaaS).
• Use process managers to ensure Horizon automatically restarts.
• Scale horizontally: run Horizon on multiple hosts and tag supervisors with identifying names so you can control restarts during deploys.

Recommended systemd unit (conceptual):

[Unit]
Description=Laravel Horizon
After=network.target
[Service]
User=www-data
Restart=always
ExecStart=/usr/bin/php /var/www/current/artisan horizon
[Install]
WantedBy=multi-user.target

Ensure graceful restarts with php artisan horizon:terminate during deployments so workers finish current jobs.

Security and Redis hardening

• Use strong authentication for Redis and network-level controls (VPCs, firewall rules).
• Limit access to Redis to only app servers and monitoring tools.
• Monitor Redis command latencies and slowlog.

Refer to NIST and OWASP guidance for secure operations and threat modeling: NIST Cybersecurity Framework, OWASP.

Real-World Scenarios

Real-World Scenarios

Scenario 1: Sudden spike in email jobs

A marketing campaign triggers a 10x increase in email jobs. The team used an auto-balanced supervisor for mail and an isolated supervisor for transactional emails. Auto balance shifted workers toward the mail queue, but monitoring alerted on retries and SMTP rate limits, prompting throttling and staged dispatch.

Scenario 2: Memory leak in image processing worker

An image-processing job introduced a leak and crashed workers after a few hours. Multiple small instances with capped processes limited blast radius; alerting on OOM kills and rising restart counts led to a quick rollback and patch.

Scenario 3: Redis latency during backups

A scheduled Redis RDB snapshot caused GC-like latency, increasing job runtimes and causing timeouts. The ops team moved queue traffic to a read-replica and adjusted snapshot schedule to off-peak times while tuning persistence settings.

Checklist

Checklist

• Set QUEUE_CONNECTION=redis in .env and install Horizon
• Publish and review config/horizon.php supervisor settings
• Define supervisors per job-type with appropriate process counts
• Configure balance strategy (simple/auto/false) for each supervisor
• Set up external monitoring (Prometheus/Grafana or APM) for queue length and failure rate
• Configure alerting for backlog, failure spikes, and Horizon process health
• Harden Redis network access and authentication
• Use systemd or process manager to run Horizon with auto-restart and graceful terminations
• Add runbooks: what to do when backlog > threshold, or failure rate spikes

Latest News & Trends

• Growing interest in observability for background processing: more teams instrument P95/P99 runtimes for jobs.
• Serverless queue patterns are increasingly used, but dedicated Horizon+Redis setups remain common for predictable latency and control.
• Integrations between Horizon metrics and APMs (Datadog, New Relic) are improving to give end-to-end traces for background jobs.

Operational runbook highlights

• On alert (queue backlog): check Horizon dashboard, Redis INFO, and recent deploys. If backlog persists, scale up supervisor processes or add instances.
• On high failure rate: inspect failed job payloads, recent code changes, and external dependencies (APIs, storage). Roll back if necessary.

FAQ

(See the FAQ section below for quick answers to common operational questions.)

Key considerations for scaling

• Horizontal scaling: add hosts running Horizon supervisors tagged for different roles.
• Vertical scaling: increase instance CPU/memory and adjust processes count.
• Partition queues by priority and SLA to avoid high-priority job starvation.

How Prateeksha Web Design runs Horizon in production

Prateeksha Web Design runs laravel horizon setup redis queues across dedicated instances, with isolated supervisors per job class, Prometheus telemetry, and automated alerts. They prefer conservative auto-balancing for variable workloads, systemd-managed Horizon processes, and Redis instances on private networks with monitoring and backup policies.

Chat with us now Contact us today.