Managing background jobs in Laravel can get overwhelming fast if you don’t have the right tools. Laravel 12 Horizon is a queue monitoring dashboard and configuration tool that gives you real-time insights into Redis-powered queues, job metrics, and worker management—all through a clean web interface.
The Laravel Horizon dashboard replaces manual queue worker configuration with a single, version-controlled file. That makes scaling and monitoring so much easier.
Laravel 12 brings some updated features to Horizon. Queue management is now more efficient than ever.
Developers can track job throughput, monitor failures, and balance worker processes across multiple queues automatically. The tool handles everything from basic job processing to complex scaling scenarios with thousands of jobs per day.
Key Takeaways
- Laravel Horizon gives you a dashboard and code-driven configuration for monitoring Redis queues with real-time metrics.
- Supervisors manage worker processes and support three balancing strategies, including auto-scaling based on queue workload.
- The dashboard needs authorization configuration outside of local environments and offers job tagging, failure tracking, and retry management.
What Is Laravel 12 Horizon?
Laravel Horizon is a queue management tool with a dashboard and configuration system built for Laravel apps using Redis queues. You get to monitor background jobs, track performance metrics, and manage worker processes—all in one place.
Core Features Overview
Laravel Horizon offers a visual dashboard that displays real-time data about queue operations. The dashboard shows job throughput, runtime stats, and failure rates for your background jobs.
This tool uses code-driven configuration stored in a single file. Developers can define worker settings for different environments like production, staging, or local, and version control their queue config alongside application code.
Horizon includes automatic worker balancing across queues. The auto-balancing strategy adjusts the number of worker processes based on workload. If one queue’s got 1,000 pending jobs and another is empty, Horizon shifts more workers to the busy queue.
The system also provides job tagging and filtering features. Developers can organize jobs by categories and track specific job types in the dashboard. Failed jobs can be retried right from the interface, no command line needed.
Horizon vs. Default Laravel Queues
Laravel queues process background jobs out of the box. Default Laravel queue workers run through command-line instructions and need manual configuration for each environment.
Horizon adds real-time monitoring that standard queues just don’t have. Default queues require you to check logs or database tables to see job status, but Horizon shows this info live in a web interface.
Worker management is also different. With standard queues, you need separate commands to start workers for each queue. Horizon manages multiple workers through supervisors defined in config files, handling process scaling automatically.
Configuration storage is another difference. Default queues use command-line options that you have to document somewhere else. Horizon stores everything in config/horizon.php, so deployment is simpler across servers.
How Horizon Works with Redis
Horizon requires Redis as the queue connection. It won’t work with database or sync drivers.
You need to set Redis as the queue connection in config/queue.php before installing Horizon. Redis gives the speed needed for high-volume queue processing.
Horizon uses a reserved Redis connection called horizon for internal stuff. Don’t assign this connection to any other Redis tasks in your app.
Horizon monitors Redis queue data constantly. It tracks pending jobs, processes them through worker processes, and updates metrics in real time. All job data flows through Redis, which acts as the central hub for queue operations.
Horizon isn’t compatible with Redis Cluster right now. If you’re using Redis Cluster, you’ll need to stick with standard Redis connections.
Installing Laravel Horizon
Laravel Horizon needs Redis as the queue driver. There are four main steps: check prerequisites, install the package with Composer, publish configuration files and assets, and run database migrations to create the necessary tables.
Prerequisites and Requirements
Horizon only works with Redis-powered queues. Set your queue connection to redis in config/queue.php before moving forward.
Your app needs Redis installed and configured. Horizon doesn’t work with Redis Cluster right now. Make sure the QUEUE_CONNECTION environment variable is set to redis in your .env file.
Laravel should be running a supported version. You’ll need a working Redis connection in config/database.php. Also, you need command-line access for Artisan and Composer commands.
Install laravel/horizon via Composer
Start by running composer require laravel/horizon in your project directory. Composer downloads the package and adds it to your dependencies.
This installs the latest version compatible with your Laravel app. The package includes all the files you need for queue monitoring and management. Once Composer finishes, the laravel/horizon package is available in your application.
Laravel 12 registers the Horizon service provider for you. No need to do it manually.
Publishing Horizon Assets
After installing, run php artisan horizon to publish Horizon’s assets. This command creates the config file and dashboard assets.
The command generates a config/horizon.php file with all configuration options. You’ll find settings for environments, supervisors, and worker processes in there. This file defines how Horizon manages queue workers for different environments like production or local.
The assets include JavaScript and CSS for the dashboard. These files power the visual interface at the /horizon route.
Running Horizon Migrations
Horizon needs database tables to store job metrics and monitoring data. Run php artisan migrate to create these tables.
The migrations add tables for storing completed jobs, failed jobs, and other queue metrics. These let Horizon display historical data and stats in the dashboard. Migration files come with the Horizon package.
Once migrations finish, Horizon can track and display queue activity. The database stores info about job throughput, runtime, and failures that show up in the monitoring dashboard.
Configuring Horizon
Horizon keeps all worker configuration in one file: config/horizon.php. This code-driven configuration makes it easy to manage queue workers for different environments and track changes in version control.
Primary Configuration Options
The config/horizon.php file has several key settings that control how Horizon works. The environments option defines worker configs for each environment your app runs in. Each environment has one or more supervisors that manage groups of worker processes.
The defaults section sets base values for all supervisors unless you override them. These include connection type, queue names, and balance strategy. The use option tells Horizon which Redis connection to use for queue management.
Some important settings:
- maxProcesses – Max number of worker processes per supervisor
- minProcesses – Minimum workers per queue (when using auto balance)
- tries – Max job attempts before marking as failed
- timeout – Seconds before forcefully killing a running job
The waits config controls how long Horizon stores job metrics. trim settings decide when to clean up monitoring data.
config/horizon.php File Overview
After you run php artisan horizon:install, Laravel publishes the config file to config/horizon.php. This file organizes settings into logical sections for dashboard access, monitoring, and global defaults.
The file uses a nested array structure. At the top, you’ll see configuration for dashboard access, monitoring, and global defaults. The environments array holds environment-specific worker configs.
Key file sections:
| Section | Purpose |
|---|---|
| prefix | Redis key prefix for Horizon data |
| middleware | HTTP middleware for dashboard routes |
| waits | Metric retention timeframes |
| trim | Data cleanup schedules |
Each supervisor inside an environment can set its own connection, queue list, and balancing strategy. The config supports wildcards for catch-all environment setups.
Setting Up Different Environments
Horizon needs separate configs for each environment. The environments array usually includes production and local entries. Setting up different environments ensures you have the right worker counts and strategies for each deployment.
Production environments usually set higher maxProcesses to handle more work. Local environments use fewer workers to save system resources. The environment name matches your APP_ENV value.
A wildcard * environment acts as a fallback if Horizon can’t find a matching config. This helps avoid errors when deploying to new environments without updating the config file.
Each environment needs at least one supervisor with its own settings. Multiple supervisors let you use different balancing strategies or worker counts for specific queues. Give supervisors descriptive names so you know what they’re for.
Supervisors and Workers
Supervisors manage groups of worker processes in Horizon. Each supervisor controls how many workers run and which queues they handle.
Worker process settings determine the resources available for job processing. Proper scaling keeps your queues balanced, no matter how much the workload changes.
Supervisor Configuration
Every environment in Horizon’s configuration can have one or more supervisors. The config file lists supervisors with unique names like supervisor-1, but honestly, you can name them whatever fits your project.
Supervisors look after a group of worker processes. They keep an eye on these workers and decide how to spread them across different queues.
You might want several supervisors in one environment if you need different balancing strategies or worker counts for certain queues.
The configuration file includes a few core options:
- connection – Which Redis connection to use
- queue – An array of queue names to handle
- balance – Balancing strategy (
auto,simple, orfalse) - force – Should jobs be processed during maintenance mode?
If you enable force in the supervisor config, jobs still get processed during maintenance mode. Otherwise, Horizon pauses job processing.
Worker Process Settings
Worker process settings control how each worker acts when handling jobs. The minProcesses option sets the least number of worker processes per queue. You can’t set it lower than 1.
The maxProcesses option puts a ceiling on how many workers Horizon can spin up across all queues.
If you set maxProcesses to 0, the supervisor won’t start any processes at all. The timeout value tells Horizon how long a worker can run a job before it gets the boot.
Keep this timeout less than the retry_after value in your queue config. That way, you avoid duplicate jobs.
The tries setting decides how many times a job gets retried before it’s marked as failed. If you set tries to 0, Horizon will keep trying forever.
The backoff value controls how long Horizon waits before retrying failed jobs. You can use a single value or an array for exponential backoff, like [1, 5, 10].
Scaling Queue Workers
The auto balancing strategy tweaks worker counts based on the current queue load. If a queue starts piling up jobs, Horizon adds more workers until things settle down.
The autoScalingStrategy option chooses how to assign workers, either by time or size.
The time strategy guesses how long it’ll take to clear the queue and assigns workers accordingly. The size strategy just looks at the total job count.
Two more settings control how fast scaling happens:
- balanceMaxShift – Max processes to add or remove per cycle
- balanceCooldown – Seconds to wait between scaling changes
If you set balanceMaxShift to 1 and balanceCooldown to 3, Horizon will only add or remove one process every three seconds. This helps avoid wild swings in worker counts.
Queue Management and Job Processing
Horizon changes how you handle queues by giving you more control over multiple queues, priorities, and performance stats. Job tagging and payload monitoring let teams see exactly how background jobs perform in production.
Managing Multiple Queues
Horizon lets you run several queues in a single app. Each supervisor can take care of one or more queues, depending on your workload.
You decide which queues each supervisor should watch in the config file. A common setup might split emails, notifications, and data processing into their own queues.
'supervisor-1' => [
'connection' => 'redis',
'queue' => ['emails', 'notifications', 'reports'],
'balance' => 'auto',
'maxProcesses' => 10,
],
Workers spread themselves across these queues based on whatever balancing strategy you pick. Laravel Horizon’s queue management keeps all worker settings in one file, so you can tweak things during deployment without much hassle.
Queue Prioritization Strategies
Queue priority decides which jobs get picked first if multiple queues have waiting jobs. Horizon works through queues in the order you list them in the config array.
If you want critical jobs to run first, just list those queues first. For example, put your payment queue before the newsletter queue.
'queue' => ['payments', 'emails', 'default'],
Balancing strategies affect how workers handle priorities. The simple strategy sticks to a fixed number of workers per queue. The auto strategy shifts workers around based on queue size.
If you set balance to false, Horizon skips all automatic balancing. Workers just process jobs from the queues in order, no fancy adjustments.
Background Job Tagging
Tags help you organize and filter jobs in the Horizon dashboard. Developers can add tags to jobs by setting them in the job class.
public function tags()
{
return ['user:'.$this->user->id, 'email'];
}
The dashboard shows jobs grouped by tags, which makes it easier to track certain job types or user tasks.
When you’re dealing with thousands of jobs, tagging becomes a lifesaver. Teams can spot which categories eat up the most resources or fail the most.
Job Payloads and Metrics
Horizon tracks detailed stats for every job that runs through the system. You’ll see job throughput, runtime, and failure rates live on the dashboard.
The metrics page shows how long jobs take and how many actually finish. This info can help you spot slowdowns in your background processing.
| Metric | Description |
|---|---|
| Throughput | Jobs processed per minute |
| Runtime | Average execution time |
| Failures | Failed job count |
Job payloads hold the serialized data sent to background jobs. The dashboard shows this info for each job, which really helps when you need to debug failures.
Horizon’s monitoring tools let teams compare job performance and metrics across different environments or supervisors.
Monitoring and Horizon Dashboard
The Horizon dashboard gives you a live look at queue operations through a web interface. You can watch job processing, worker performance, and queue health right as it happens.
Laravel Horizon displays job statuses like pending, running, completed, and failed. You also get detailed views into system performance.
Accessing the Horizon Dashboard
The dashboard lives at the /horizon route after you install Horizon. By default, it only works in your local environment for security.
If you want it in other environments, you’ll need to tweak the authorization in app/Providers/HorizonServiceProvider.php. The gate definition decides who gets in on production or staging.
The gate checks user credentials before letting anyone in. If you prefer IP restrictions over user logins, change the closure signature from function (User $user) to function (User $user = null).
Real-Time Dashboard Features
The dashboard tracks job throughput and runtime as jobs process. You see current activity, worker assignments, and processing times without needing to refresh.
The dashboard breaks jobs into three groups:
- Pending Jobs: Waiting for workers
- Completed Jobs: Finished with details
- Failed Jobs: Ran into errors
You can retry failed jobs right from the dashboard. There’s tag filtering too, so you can zero in on specific types of jobs. Metrics include how long jobs ran, memory usage, and exception details if things went south.
Queue and Worker Health Monitoring
The process monitor lists active worker processes and their current status for every queue. Developers can see which queues have the most work and how workers are spread around.
Queue health indicators show wait times, job counts, and processing rates. If a queue starts piling up, the dashboard makes it obvious. Worker balancing metrics show how the auto-scaling feature is juggling process allocation.
The monitoring system lists supervisor configs and max process limits for each environment. Developers can spot performance issues by looking at job failure rates and average processing times.
Handling Job Failures and Retries
Laravel Horizon comes with tools to manage failed jobs, set up automatic retries with backoff, and get alerts when jobs fail. These features help keep your queue system reliable and let you react quickly if something breaks.
Managing Failed Jobs
Horizon gives you a dashboard that lists all failed jobs along with what went wrong. You can check out the payload, exceptions, and stack traces right there.
Retrying failed jobs is simple—just click the retry button next to a job. If you need to retry a bunch, select them and hit retry in bulk.
Failed jobs stick around until you delete them or set up automatic pruning. You can configure pruning in horizon.php by setting the trim option. This keeps the failed jobs table from getting out of hand.
The failed_jobs table stores things like queue name, connection, and timestamps. You can query this table for custom reports or analysis if you want.
Job Retries and Backoff Options
Jobs in Laravel 12 support automatic retries with the $tries and $backoff properties. $tries sets how many times to try before giving up.
public $tries = 3;
public $backoff = [60, 300, 900];
$backoff defines how long to wait between tries, in seconds. In the example, the job waits 60 seconds after the first failure, 300 after the second, and 900 after the third.
You can use a single integer for exponential backoff, and Laravel will work out the delays. Enhanced job handling in Laravel 12 brings better logging and retry features.
The $maxExceptions property lets you retry jobs only when certain exceptions pop up. That way, you don’t waste time on jobs that just won’t ever work.
Failed Job Notifications
Laravel lets developers set up notifications for failed jobs using event listeners. The JobFailed event fires whenever a job uses up all its retry attempts.
To send alerts, developers register a listener in the EventServiceProvider. You can send notifications via email, Slack, or whatever channel fits your team best.
The event gives you the job instance, exception details, and connection info. Here’s a quick example:
Event::listen(JobFailed::class, function ($event) {
// Send notification
});
Handling job failures in Horizon is important for reliability, and monitoring helps you catch problems before they get out of hand.
Teams often integrate third-party services like Sentry or Bugsnag for advanced error tracking and alerting. You can configure notification preferences per queue or globally.
This flexibility means critical queues get immediate attention, while less important ones just send summary reports. That’s a nice touch for busy teams.
Horizon Commands and Operations
Laravel provides several Artisan commands for controlling Horizon and checking worker status. These commands let you start, stop, pause, and monitor queue workers right from the terminal.
Starting and Stopping Horizon
The php artisan horizon command starts Horizon and begins monitoring queues. In production, you’ll want this running all the time—usually under a process monitor like Supervisor so it restarts if something goes wrong.
To stop Horizon gracefully, use php artisan horizon:terminate. This signals workers to finish their jobs before shutting down.
That way, you avoid interrupting jobs and keep your data safe. Before deploying new code, running horizon:terminate lets workers finish up, and then Supervisor can restart Horizon once the deployment’s done.
Pausing and Resuming Horizon
Need to pause job processing for maintenance or troubleshooting? Use php artisan horizon:pause. Workers stop picking up new jobs but finish anything they’re already working on.
Paused workers just sit idle. Jobs keep piling up in the queue until you run php artisan horizon:continue to resume everything.
Checking Horizon Status
Want to see if Horizon’s running? Try php artisan horizon:status. It returns a simple active or inactive status, which is handy for monitoring scripts or health checks.
Zero exit code means Horizon is up. Anything else means it’s not. Many sysadmins wire this into their monitoring systems to alert the team if Horizon stops processing jobs unexpectedly.
Deployment and Production Considerations
Running Horizon in production means you need solid process management to keep things running. Worker auto-balancing helps distribute jobs efficiently, and restart procedures make sure new code goes live after each deployment.
Supervisor Integration for Daemonization
Horizon needs a process monitor to stay up in production. Supervisor is the go-to tool for this, since it’ll restart Horizon if it ever crashes or stops.
On Ubuntu or Debian, install Supervisor with sudo apt-get install supervisor. The config file goes in /etc/supervisor/conf.d/horizon.conf and should include settings for your app.
A basic config lists the command to start Horizon, the user, and how many processes to run. Set numprocs to 1—Horizon manages its own workers internally.
The stopwaitsecs setting controls how long Supervisor waits before force-killing Horizon on shutdown. Set this higher than your longest job (600 seconds is usually safe for long-running stuff).
After setting up the config, run sudo supervisorctl reread, sudo supervisorctl update, and sudo supervisorctl start horizon to get things rolling.
Worker Auto-Balancing in Production
Horizon supports three balancing strategies: auto, simple, and false. The auto strategy dynamically adjusts worker allocation based on queue load, which is great for production with unpredictable workloads.
maxProcesses sets the total worker limit. minProcesses ensures each queue always has at least one worker. These settings directly affect wait times and throughput.
Auto balancing uses two timing controls. balanceMaxShift limits how many processes can be created or destroyed at once, and balanceCooldown sets how long Horizon waits between adjustments.
The autoScalingStrategy option can be time or size. Time uses estimated queue clearing duration, while size allocates workers based on job count.
Restarting Horizon After Deployment
You have to restart Horizon after every deployment to load new code. If you skip this, Horizon keeps running the old version, which can lead to weird errors or bugs.
Use php artisan horizon:terminate to stop Horizon gracefully and let Supervisor restart it. This waits for jobs to finish, so you don’t lose work in progress.
Most deployment scripts include the terminate command after dependencies and migrations, but before post-deployment tasks.
Zero-downtime deployments need careful timing. Run the restart too early, and workers process jobs with old code. Wait too long, and you risk mixing old and new versions.
Securing and Customizing the Horizon Dashboard
The Horizon dashboard shows sensitive info about jobs and performance, so security matters. Developers can restrict access with authentication middleware and tweak the dashboard’s look to match their branding.
Restricting Dashboard Access
By default, Horizon lets anyone access the dashboard in local environments but blocks everyone in production. This keeps queue metrics and job data private.
The gate method in HorizonServiceProvider controls who can get in. Edit app/Providers/HorizonServiceProvider.php to define your access rules:
protected function gate()
{
Gate::define('viewHorizon', function ($user) {
return in_array($user->email, [
'[email protected]',
]);
});
}
This checks email addresses, but you can check roles or permissions too. The gate runs before Horizon loads, blocking unauthorized users right away.
Using horizon::auth Middleware
The horizon::auth middleware is another way to secure Horizon. You can add custom logic in the HorizonServiceProvider middleware.
Laravel lets you add your own middleware to Horizon routes. You might check database permissions, verify API tokens, or connect with third-party auth systems:
protected function authorization()
{
Horizon::auth(function ($request) {
return $request->user() &&
$request->user()->isAdmin();
});
}
Horizon::auth takes a callback that returns true or false. If it’s false, Laravel blocks the request with a 403 error.
Customizing Dashboard Appearance
You can customize Horizon by editing config/horizon.php. This file controls the dashboard path, refresh intervals, and display options.
Changing the dashboard path adds a bit of security by obscurity:
'path' => 'admin/queues',
Teams can also tweak trim settings to decide how long Horizon keeps completed and failed job records. The trim config takes values in minutes for recent, failed, and monitored jobs.
Best Practices and Optimization Tips
Good configuration and monitoring are key for high queue performance with Laravel Horizon. Set proper timeout values, balance workers smartly, and track metrics like job throughput and runtime to keep background tasks running smoothly.
Performance Tuning
The timeout setting controls how long a worker can run before it’s killed. The timeout should always be less than the retry_after value in your queue config to avoid duplicate job processing.
Set the tries option at the supervisor level to control job attempts before failure. If you use middleware like WithoutOverlapping or RateLimited, increase the tries value since these use up attempts. Setting tries to 0 allows unlimited retries if you’re not sure how many you’ll need.
Backoff Configuration Options:
- Simple backoff: Use
backoff => 10to wait 10 seconds between retries - Exponential backoff: Use
backoff => [1, 5, 10]to increase wait times with each attempt
maxProcesses limits how many worker processes Horizon can create. This prevents your server from getting overwhelmed during heavy traffic.
Queue Scaling Strategies
Horizon gives you three balancing strategies to control worker distribution. auto adjusts workers based on queue size, which is ideal when workloads fluctuate.
minProcesses sets the minimum workers per queue (must be at least 1). maxProcesses caps the total workers across all queues. For example, minProcesses => 1 and maxProcesses => 10 ensures every queue has one worker, but never more than 10 total.
balanceMaxShift and balanceCooldown control how fast scaling happens. Setting balanceMaxShift => 1 and balanceCooldown => 3 means one process is added or removed every three seconds. autoScalingStrategy chooses between time (estimated completion) or size (job count).
balance => 'simple' splits workers evenly, no matter the workload. balance => false turns off auto-balancing.
Monitoring Job Throughput and Wait Time
Horizon’s dashboard shows key metrics like job throughput, runtime, and failure rates. You can see how many jobs run per minute and how long jobs wait in the queue.
Job runtime stats help you spot tasks that take too long. If a job is slow, maybe it needs optimization or a dedicated queue with a higher timeout. Long wait times usually mean you need more workers for the current load.
The metrics endpoint lets you pull queue stats into external monitoring tools. Failed job counts help you catch problematic tasks that need fixing.
To keep the dashboard uncluttered, you can silence specific job classes. Just add their names to the silenced array in Horizon’s config, and they’ll stay out of the completed jobs list.
Frequently Asked Questions
To install Horizon, you’ll need Redis as your queue driver. The process involves running specific Composer and Artisan commands, and you’ll want to secure the dashboard in production by tweaking the authorization gate to limit access by user or IP.
How can I install Laravel Horizon for a Laravel 12 project?
First, make sure your Laravel 12 app uses Redis as the queue connection. Open config/queue.php and set the queue connection to redis.
Next, run composer require laravel/horizon in your project directory. Once Composer finishes, publish Horizon’s assets with php artisan horizon:install.
This command creates the config/horizon.php file, where you’ll find all the queue worker settings. By default, it includes environment-specific options for both local and production.
What are the best practices for configuring Laravel Horizon with multiple servers?
Take a close look at the environments section in config/horizon.php. Each environment can list several supervisors, each one managing a group of workers.
Set up separate supervisor configs for different servers or processing needs. The maxProcesses option controls how many worker processes a supervisor can run at once.
Use minProcesses to make sure every queue keeps at least one worker running. Tweak balanceMaxShift and balanceCooldown to control how quickly Horizon adds or removes workers as jobs come in.
If you work across multiple environments, try the wildcard (*) for default settings. It helps keep things consistent and avoids repeating yourself everywhere.
Where can I find comprehensive documentation for Laravel Horizon?
You’ll find everything you need in the official Laravel 12 documentation. It covers installation, configuration, balancing strategies, and deployment.
Each option in the docs comes with a description and example code. You can check sections on dashboard authorization, job timeouts, and notification settings if you need specifics.
The docs even dig into advanced stuff like exponential backoff and silenced jobs. There’s also advice on hooking Horizon into Laravel’s core queue services.
How can I secure the Laravel Horizon dashboard in a production environment?
The dashboard lives at /horizon and needs authorization outside of local environments. By default, HorizonServiceProvider.php holds a gate definition for access.
To restrict access, update the gate() method to check user emails or whatever criteria fits your needs. The closure gets the authenticated user and returns true or false based on your logic.
If you want to use IP restrictions instead of user authentication, change the closure signature to function (User $user = null). This way, Laravel skips authentication but still lets you control access.
You can also check user roles or permissions by customizing the gate. Whoever passes the gate can see metrics, failed jobs, and worker stats.
What are the alternatives to using Laravel Horizon for job queue monitoring?
Laravel’s default queue worker gives you basic job processing, but there’s no dashboard. You can run php artisan queue:work to process jobs and see status info in your console.
Some third-party packages offer queue monitoring with different features and interfaces. A few tools even work with queue drivers other than Redis.
If you want total control, you can build custom monitoring using Laravel’s queue events and logging. It takes more work, but you get exactly what you want.
Paid monitoring services can give you queue insights as part of bigger performance tracking. They usually offer alerting, historical data, and integrations with other tools you might already use.
How can I troubleshoot common issues encountered when using Laravel Horizon?
Connection issues pop up a lot when the Redis connection isn’t set up right. If you’re using Redis Cluster, Horizon just won’t support it—so you’ll need to stick with standard Redis connections.
Worker processes might refuse to start if the APP_ENV environment variable doesn’t match one defined in config/horizon.php. Tossing in a wildcard environment configuration usually keeps that from happening.
If jobs start timing out too soon, you probably need to tweak the timeout value. You can do this at the supervisor level or right on the job class itself.
Honestly, the timeout should always be shorter than the retry_after value in config/queue.php, or you risk jobs getting processed twice. That’s just asking for trouble.
Memory issues can show up when worker processes start hogging RAM. Restarting Horizon every so often during deployments helps clear up memory leaks and makes sure workers are running the latest code.
If jobs aren’t showing up in the dashboard, they might be silenced. The silenced configuration option or the Silenced interface can hide jobs from the completed list.
It’s worth checking the configuration file to see if certain job classes or tags are actually being hidden. Sometimes it’s just a small detail that gets overlooked.
