Why bother with Horizon when I can just run the queue worker?

Look, if you're running a tiny project, php artisan queue:work is perfectly fine. But the moment you move to production with actual users, that command becomes a black box. You have no idea if your jobs are piling up, if a specific job is crashing your worker, or if your "high priority" queue is being choked by a thousand "low priority" tasks.

I've spent way too many hours digging through text logs trying to figure out why a customer didn't receive a welcome email. Horizon changes that by giving you a beautiful, real-time dashboard. It tells you exactly how many jobs are pending, how long they're taking, and which ones failed. It effectively turns your Redis queue into something you can actually see and manage without having to SSH into your server and run redis-cli commands like a caveman.

How do I actually manage different priorities for my jobs?

This is where Horizon really shines. In a standard Laravel setup, you'd have to manage multiple supervisor processes for different queues. With Horizon, you do it all in config/horizon.php. Let's say you have a "notifications" queue (fast, high priority) and a "video-processing" queue (slow, resource-heavy).

You don't want your video uploads to stop your password reset emails from going out. You can set up a "balanced" strategy that automatically shifts worker resources where they're needed most. Here is how a typical configuration looks:

'environments' => [
    'production' => [
        'supervisor-1' => [
            'connection' => 'redis',
            'queue' => ['notifications', 'default', 'video-processing'],
            'balance' => 'auto',
            'processes' => 10,
            'tries' => 3,
        ],
    ],
],

By setting 'balance' => 'auto', Horizon monitors the workload. If the video-processing queue suddenly gets 10,000 jobs, Horizon will automatically allocate more of those 10 processes to that queue, then shift them back to notifications once the spike is over. It's a lifesaver for maintaining a snappy user experience.

What happens when a job fails and how do I handle it in Horizon?

We've all been there: a third-party API goes down, and suddenly 500 of your jobs fail. In a raw queue setup, you're stuck running php artisan queue:retry all and hoping for the best, or manually deleting bad jobs from a database table.

In Horizon, you get a "Failed Jobs" tab. You can see the exact exception that caused the failure and the payload that was sent with the job. If you realize the failure was caused by a bug you just patched in your code, you can select the failed jobs and click "Retry" right from the browser. I generally recommend keeping your tries count low in the config—maybe 3—so you aren't wasting CPU cycles on a job that's fundamentally broken. Once it hits that limit, Horizon parks it in the failed list for you to inspect manually.

📋 Practical Task

Configuring an Auto-Balancing Worker for an Order Fulfillment System

You are managing an e-commerce site. You have three queues: orders (critical), emails (standard), and reports (low priority/heavy). Currently, the reports queue is blocking the orders queue because you are using a simple sequential worker.

Your task:

• Modify your config/horizon.php file to create a production environment configuration.
• Set up a supervisor that handles all three queues: orders, emails, and reports.
• Implement the auto balancing strategy to ensure the orders queue is prioritized during spikes.
• Configure the supervisor to use a total of 8 processes and a maximum of 3 retries per job.
• Explain in a brief comment in your code why 'balance' => 'auto' is preferable here over 'balance' => 'simple'.