Modern web applications often need to perform tasks that take time to complete.
Sending emails, processing images, generating reports, importing large datasets, calling external APIs, and sending notifications are common examples.
If these tasks run directly during an HTTP request, users may have to wait while the server finishes processing them.
Laravel solves this problem with Jobs and Queues.
In this guide, you’ll learn how to create background jobs and queues in Laravel, how Laravel queue workers work, how to dispatch jobs, how to handle failures and retries, and how to build a production-ready queue workflow.
What Are Background Jobs in Laravel?
A background job is a task that Laravel can process separately from the user’s current request.
For example, imagine a user registers on your website.
Without a queue:
User Registration
│
▼
Create Account
│
▼
Send Welcome Email
│
▼
Generate Notification
│
▼
Update Analytics
│
▼
Response to User
The user has to wait for every operation to finish.
With a queue:
User Registration
│
▼
Create Account
│
├──────────────► Queue Job
│ │
▼ ▼
Response to User Queue Worker
│
├── Send Email
├── Notification
└── Analytics
The application can respond quickly while the queue worker processes background tasks.
What Is a Laravel Queue?
A Laravel queue provides a way to defer time-consuming tasks until later.
Instead of executing a task immediately, Laravel places a job into a queue.
A queue worker then retrieves and executes that job.
The basic architecture looks like this:
Laravel Application
│
▼
Dispatch Job
│
▼
┌─────────────┐
│ Queue │
└─────────────┘
│
▼
Queue Worker
│
▼
Process Job
│
▼
Complete
This approach improves application responsiveness and allows background processing to scale independently.
Why Use Laravel Jobs and Queues?
Queues are useful when a task doesn’t need to finish before the user receives a response.
Common examples include:
- Sending emails
- Sending notifications
- Processing uploaded images
- Generating PDFs
- Creating reports
- Importing CSV files
- Exporting large datasets
- Calling third-party APIs
- Processing webhooks
- Sending SMS messages
- Updating search indexes
- Performing analytics calculations
- Processing video or media files
For example, an e-commerce application might use a queue after an order is placed:
Order Created
│
├──► Send Confirmation Email
├──► Generate Invoice
├──► Notify Warehouse
├──► Update Inventory
└──► Send Analytics Event
These operations don’t necessarily need to delay the checkout response.
Laravel Jobs vs Queues
Although the terms are often used together, they represent different things.
| Concept | Purpose |
|---|---|
| Job | Defines the task that should be performed |
| Queue | Stores jobs until they are processed |
| Queue Worker | Retrieves and executes jobs |
| Queue Connection | Defines where queued jobs are stored |
| Failed Jobs | Stores jobs that could not be completed |
A simple analogy:
Job = Task
Queue = Waiting line
Worker = Employee processing tasks
How Laravel Queue Processing Works
The complete workflow looks like this:
1. User performs an action
│
▼
2. Laravel creates a Job
│
▼
3. Job is dispatched
│
▼
4. Queue stores the Job
│
▼
5. Queue Worker picks it up
│
▼
6. Job's handle() method runs
│
▼
7. Job succeeds or fails
This separation is what makes background processing possible.
Step 1: Configure a Queue Connection
Laravel supports several queue backends depending on your application’s requirements.
Common options include:
- Database
- Redis
- Amazon SQS
- Other supported queue services
- Synchronous execution for development/testing
The appropriate queue configuration depends on your Laravel version and infrastructure.
For a simple local development setup, a database-backed queue can be convenient.
Using the Database Queue
A database queue stores pending jobs in your application’s database.
Configure your .env file with the appropriate queue connection:
QUEUE_CONNECTION=database
Then create the queue table using Laravel’s queue migration command.
Depending on your Laravel version, the command may be:
php artisan make:queue-table
Then run:
php artisan migrate
This creates the database structure required to store queued jobs.
Using Redis for Laravel Queues
Redis is a popular choice for applications that need fast queue processing.
Your environment might contain configuration similar to:
QUEUE_CONNECTION=redis
Redis can be especially useful when an application has a large number of background jobs.
A typical architecture looks like:
Laravel Application
│
▼
Redis
│
▼
Queue Workers
│
├── Worker 1
├── Worker 2
└── Worker 3
Multiple workers can process jobs concurrently.
Step 2: Create a Laravel Job
Laravel provides an Artisan command for generating jobs.
Run:
php artisan make:job ProcessOrder
Laravel creates a class similar to:
app/Jobs/ProcessOrder.php
The generated job contains a handle() method where the task logic is executed.
Basic Laravel Job Example
A simple job may look like:
<?php
namespace App\Jobs;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
class ProcessOrder implements ShouldQueue
{
use Queueable;
public function handle(): void
{
// Background task logic
}
}
The important part is:
implements ShouldQueue
This tells Laravel that the job should be processed through the queue system.
Step 3: Add Data to a Job
Most real-world jobs need information about what they should process.
For example, an order-processing job may need an order ID.
class ProcessOrder implements ShouldQueue
{
use Queueable;
public function __construct(
public int $orderId
) {
}
public function handle(): void
{
// Process the order
}
}
Now you can dispatch the job with an order ID.
ProcessOrder::dispatch($order->id);
Step 4: Dispatch a Laravel Job
Once the job is created, you can dispatch it.
For example:
ProcessOrder::dispatch($order->id);
Laravel places the job onto the configured queue.
The request can then continue without performing the background operation immediately.
Dispatching Jobs From a Controller
For example:
use App\Jobs\ProcessOrder;
public function store(Request $request)
{
$order = Order::create([
'user_id' => auth()->id(),
'total' => $request->total,
]);
ProcessOrder::dispatch($order->id);
return response()->json([
'message' => 'Order created successfully.',
'order' => $order,
]);
}
The controller creates the order and dispatches the background job.
The queue worker processes the job separately.
Step 5: Run the Laravel Queue Worker
Creating and dispatching a job isn’t enough.
A worker must process the queued jobs.
Run:
php artisan queue:work
The worker continuously checks the queue for pending jobs.
The workflow becomes:
Controller
│
▼
dispatch()
│
▼
Queue
│
▼
queue:work
│
▼
Job::handle()
Understanding queue:work
The command:
php artisan queue:work
starts a long-running queue worker.
It processes jobs as they become available.
For example:
Queue
│
├── Job A
├── Job B
├── Job C
└── Job D
│
▼
Queue Worker
│
├── Process A
├── Process B
├── Process C
└── Process D
queue:work vs queue:listen
Laravel developers may encounter both commands:
php artisan queue:work
and:
php artisan queue:listen
The queue:work command starts a long-running worker and is generally preferred for production queue processing.
queue:listen reloads the framework between jobs and is mainly useful in development scenarios where code changes need to be picked up immediately.
For production environments, use an appropriate worker management strategy rather than relying on a manually launched terminal process.
Delaying a Laravel Job
Sometimes you don’t want a job to execute immediately.
Laravel allows you to delay a job.
For example:
ProcessOrder::dispatch($order->id)
->delay(now()->addMinutes(10));
This places the job into the queue with a delay.
Useful examples include:
- Sending reminder emails
- Delaying notifications
- Subscription reminders
- Scheduled follow-ups
- Payment retry workflows
Queueing an Email
Sending emails is one of the most common queue use cases.
Instead of:
Mail::to($user->email)
->send(new WelcomeEmail($user));
you can queue the email when appropriate:
Mail::to($user->email)
->queue(new WelcomeEmail($user));
The email is then handled by Laravel’s queue system.
Creating a Job for Image Processing
Suppose users upload profile images.
Image processing can take time:
Upload Image
│
▼
Save Original
│
▼
Dispatch ProcessImage Job
│
▼
Return Response
The job can then resize or optimize the image in the background.
For example:
class ProcessImage implements ShouldQueue
{
use Queueable;
public function __construct(
public string $imagePath
) {
}
public function handle(): void
{
// Resize image
// Optimize image
// Generate thumbnails
}
}
Dispatch it:
ProcessImage::dispatch($path);
This prevents image processing from slowing down the upload request.
Passing Eloquent Models to Jobs
Laravel supports passing model instances to jobs.
For example:
class ProcessOrder implements ShouldQueue
{
use Queueable;
public function __construct(
public Order $order
) {
}
public function handle(): void
{
$this->order->update([
'processed' => true,
]);
}
}
Laravel serializes the model information and retrieves the model when the job is processed.
However, be careful about passing large relationships or unnecessary data with jobs.
Passing an ID is often a simpler and more predictable approach:
public function __construct(
public int $orderId
) {
}
Then retrieve the model inside handle():
public function handle(): void
{
$order = Order::findOrFail($this->orderId);
// Process order
}
Job Dependencies and Services
Avoid putting large amounts of business logic directly into the job class.
A job can call a dedicated service:
class ProcessOrder implements ShouldQueue
{
use Queueable;
public function __construct(
public int $orderId
) {
}
public function handle(OrderService $orderService): void
{
$orderService->process($this->orderId);
}
}
This keeps the job focused on queue execution while the service contains reusable business logic.
Laravel Job Retry Attempts
Jobs can fail for temporary reasons.
For example:
- External API unavailable
- Database temporarily unavailable
- Network timeout
- Third-party service error
You can configure retry attempts.
For example:
public int $tries = 3;
This tells Laravel to attempt the job multiple times before considering it failed.
Job Backoff
You can also configure a delay between retry attempts.
For example:
public function backoff(): int
{
return 10;
}
This waits before retrying a failed job.
For more advanced retry strategies, you can use an array:
public function backoff(): array
{
return [10, 30, 60];
}
This can be useful when external services need time to recover.
Job Timeout
Long-running jobs can have a timeout.
For example:
public int $timeout = 120;
This gives the job a maximum execution period.
Timeout values should be chosen based on the actual work being performed and the queue worker configuration.
Handling Failed Jobs
Laravel can store information about jobs that permanently fail.
A failed-job table can be created using Laravel’s queue tooling.
For example:
php artisan make:queue-failed-table
Then run:
php artisan migrate
Your application can then record failed jobs for later investigation.
Viewing Failed Jobs
To view failed jobs:
php artisan queue:failed
This can show information such as:
ID
Connection
Queue
Class
Failed At
This is useful when debugging background processing.
Retrying Failed Jobs
You can retry a failed job:
php artisan queue:retry <id>
For example:
php artisan queue:retry 15
You can retry all failed jobs:
php artisan queue:retry all
Be careful when retrying jobs that perform external side effects.
For example, blindly retrying a payment job could potentially result in duplicate operations if the original request actually succeeded but the application failed to receive the response.
Forgetting Failed Jobs
To remove a specific failed job:
php artisan queue:forget <id>
To remove all failed jobs:
php artisan queue:flush
Only remove failed-job records when you no longer need them for debugging or auditing.
The failed() Method
Jobs can define a failed() method to handle permanent failure.
For example:
public function failed(?Throwable $exception): void
{
// Notify administrator
// Record failure
// Update application state
}
This can be useful for:
- Logging
- Sending administrator notifications
- Updating order status
- Recording failure information
- Triggering fallback processes
Job Middleware
Laravel jobs can use middleware to control job execution.
For example, middleware can help with:
- Rate limiting
- Preventing overlapping jobs
- Throttling
- Locking
- Custom execution rules
This is particularly useful for jobs that interact with external APIs.
A simplified structure looks like:
Job
│
▼
Job Middleware
│
├── Rate Limit
├── Lock
├── Validation
└── Custom Rules
│
▼
handle()
Preventing Duplicate Jobs
Sometimes the same job may be dispatched multiple times.
For example:
User clicks button
│
├── Request 1 → Job A
└── Request 2 → Job B
If both jobs perform the same operation, you may get duplicate processing.
Laravel provides mechanisms for unique jobs and job middleware that can help prevent overlapping or duplicate work.
Use these features when the operation must be processed only once or only one instance should run at a time.
Queue Priorities
Some jobs are more important than others.
For example:
High Priority
│
├── Payment Processing
└── Security Notification
Low Priority
│
├── Analytics
└── Report Generation
Laravel supports named queues.
You can dispatch a job to a specific queue:
ProcessOrder::dispatch($order->id)
->onQueue('high');
Then run a worker for that queue:
php artisan queue:work --queue=high
You can also process multiple queues in priority order:
php artisan queue:work --queue=high,default,low
This allows higher-priority jobs to be processed before lower-priority jobs.
Queue Connections vs Queue Names
These two concepts are easy to confuse.
A queue connection determines how jobs are stored or transported.
Examples:
database
redis
sqs
A queue name identifies a specific queue within that connection.
For example:
Connection: redis
Queues:
high
default
low
This separation makes it possible to organize background workloads.
Running Multiple Queue Workers
A production application may need multiple workers.
For example:
Redis
│
┌───────────┼───────────┐
▼ ▼ ▼
Worker 1 Worker 2 Worker 3
│ │ │
▼ ▼ ▼
Jobs Jobs Jobs
Multiple workers allow several jobs to be processed concurrently.
The number of workers should be based on:
- Job volume
- CPU
- Memory
- Database capacity
- External API limits
- Expected processing time
More workers aren’t always better.
Queue Worker Memory
Long-running workers can consume memory over time.
You can configure worker limits such as:
php artisan queue:work --memory=256
When a worker reaches the configured memory threshold, Laravel can stop it so a process manager can restart it.
Queue Worker Time Limits
You can also control how long a worker should run:
php artisan queue:work --max-time=3600
This can be useful with process supervisors that automatically restart workers.
Laravel Queue Monitoring
For production applications, queue monitoring is important.
You should monitor:
- Number of pending jobs
- Failed jobs
- Job processing time
- Worker health
- Memory usage
- Queue latency
- External service failures
Laravel applications can use monitoring tools such as Laravel Horizon when Redis queues are used.
Laravel Horizon
Laravel Horizon provides a dashboard and monitoring system for Redis-powered Laravel queues.
It helps you monitor:
- Queue throughput
- Runtime
- Failed jobs
- Worker processes
- Queue workload
- Job statistics
A typical architecture looks like:
Laravel Application
│
▼
Redis
│
▼
Laravel Horizon
│
├── Worker Management
├── Queue Monitoring
├── Job Metrics
└── Failed Jobs
Horizon is especially useful for applications with substantial queue workloads.
Laravel Queue Scheduling vs Queues
Queues and scheduled tasks solve different problems.
| Feature | Queue | Scheduler |
|---|---|---|
| Purpose | Process background work | Run tasks at specific times |
| Example | Send email | Generate daily report |
| Execution | Worker | Scheduler |
| Timing | Usually as soon as available | Scheduled |
| Common Command | queue:work | schedule:run |
They can also work together.
For example:
Daily Schedule
│
▼
Generate Report Job
│
▼
Queue
│
▼
Worker
│
▼
Report Generated
Real-World Example: Sending Order Emails
Consider an e-commerce application.
When a customer places an order:
Customer
│
▼
Checkout
│
▼
Create Order
│
├──────────────► Dispatch Email Job
│ │
▼ ▼
Response Queue
│
▼
Queue Worker
│
▼
Send Confirmation
The customer doesn’t have to wait for the email provider to respond.
Real-World Example: CSV Import
Large CSV imports are another excellent queue use case.
Without queues:
Upload CSV
│
▼
Process 100,000 rows
│
▼
Long HTTP Request
│
▼
Timeout / Slow Response
With queues:
Upload CSV
│
▼
Store File
│
▼
Dispatch Import Job
│
▼
Return Response
│
▼
Queue Worker
│
▼
Process Data in Chunks
For large datasets, consider splitting the import into multiple smaller jobs rather than creating one enormous job.
Real-World Example: Image Processing
A media-heavy application can use queues to process uploaded files.
Upload Image
│
▼
Store Original
│
▼
ProcessImage Job
│
├── Resize
├── Compress
├── Create Thumbnail
└── Generate Web Version
This keeps the upload endpoint responsive.
Common Laravel Queue Mistakes
1. Dispatching Jobs Without a Worker
You may dispatch:
ProcessOrder::dispatch($order->id);
but nothing happens because no worker is processing the queue.
Run:
php artisan queue:work
in development.
In production, use a reliable process manager or hosting service to keep workers running.
2. Putting Too Much Data Into a Job
Avoid passing large objects or unnecessary relationships.
Instead of:
public function __construct(
public $largeCollection
) {
}
consider passing identifiers:
public function __construct(
public int $orderId
) {
}
Then load what you need inside handle().
3. Ignoring Failed Jobs
A queue can appear healthy while important jobs are failing.
Regularly monitor:
php artisan queue:failed
and investigate recurring failures.
4. Making Jobs Too Large
A job that performs ten unrelated operations becomes difficult to retry and debug.
Prefer focused jobs.
For example:
ProcessOrder
SendOrderEmail
GenerateInvoice
UpdateInventory
instead of one giant:
ProcessEverything
5. Not Considering Idempotency
A job can sometimes run more than once.
Design important operations so retrying them doesn’t create unwanted duplicate effects.
This is especially important for:
- Payments
- Orders
- External API requests
- Notifications
- Inventory changes
Laravel Queue Best Practices
Keep Jobs Small and Focused
Each job should ideally have one clear responsibility.
Pass IDs When Appropriate
Passing a model ID and retrieving fresh data inside handle() can make jobs easier to reason about.
Use Retries Carefully
Retries are useful for temporary failures but dangerous for operations that aren’t safe to repeat.
Use Timeouts
Don’t allow a worker to become permanently stuck on one task.
Monitor Failed Jobs
Production applications should have a strategy for detecting and handling failed jobs.
Use Dedicated Queues
Separate high-priority and low-priority workloads when necessary.
Use Redis and Horizon for Larger Workloads
For applications with significant queue processing requirements, Redis combined with Horizon can provide powerful monitoring and worker management.
Don’t Put User-Facing Work in Unnecessary Queues
Not every operation needs to be asynchronous. If the user needs an immediate result, processing it in the request may be more appropriate.
Laravel Jobs and Queues Cheat Sheet
Create a Job
php artisan make:job ProcessOrder
Run Queue Worker
php artisan queue:work
View Failed Jobs
php artisan queue:failed
Retry a Failed Job
php artisan queue:retry <id>
Retry All Failed Jobs
php artisan queue:retry all
Remove Failed Job
php artisan queue:forget <id>
Clear Failed Jobs
php artisan queue:flush
Dispatch Job
ProcessOrder::dispatch($order->id);
Dispatch With Delay
ProcessOrder::dispatch($order->id)
->delay(now()->addMinutes(10));
Dispatch to Specific Queue
ProcessOrder::dispatch($order->id)
->onQueue('high');
Background Jobs Architecture
A scalable Laravel queue architecture can look like:
┌──────────────────┐
│ Laravel Web App │
└────────┬─────────┘
│
▼
Dispatch Jobs
│
▼
┌──────────────────┐
│ Queue Backend │
│ Redis / Database │
└────────┬─────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Worker 1 Worker 2 Worker 3
│ │ │
▼ ▼ ▼
Job A Job B Job C
│ │ │
└───────────────┼───────────────┘
▼
External Services
This architecture allows background processing to scale separately from the web application.
Frequently Asked Questions
What is a job in Laravel?
A Laravel job is a class that represents a specific task your application needs to perform. Jobs can run immediately or be placed on a queue for background processing.
What is a queue in Laravel?
A Laravel queue stores jobs that should be processed later. A queue worker retrieves those jobs and executes them.
How do I create a background job in Laravel?
Run:
php artisan make:job ProcessOrder
Implement ShouldQueue, add your processing logic to handle(), and dispatch the job using:
ProcessOrder::dispatch($order->id);
How do I run Laravel queue jobs?
Run:
php artisan queue:work
The worker continuously processes available jobs.
Why is my Laravel queued job not running?
Check that:
- Your queue connection is configured correctly.
- The job was actually dispatched.
- A queue worker is running.
- The queue backend is available.
- The job hasn’t failed.
- The worker is listening to the correct queue.
You can inspect failures with:
php artisan queue:failed
How do I retry failed Laravel jobs?
Use:
php artisan queue:retry <id>
or retry all failed jobs:
php artisan queue:retry all
Should I use Redis or a database for Laravel queues?
Both can work.
A database queue can be convenient for smaller applications and simple setups. Redis is often preferred for higher-throughput queue workloads and works well with Laravel Horizon.
The right choice depends on your application’s scale and infrastructure.
Are Laravel queues suitable for sending emails?
Yes. Sending emails is one of the most common use cases for queues because email delivery can take time and shouldn’t always block an HTTP request.
How many Laravel queue workers should I run?
There is no universal number. Start based on workload and server resources, then monitor queue latency, CPU, memory, job duration, and failures to determine whether additional workers are necessary.
Key Takeaways
- Laravel Jobs define background tasks.
- Laravel Queues store jobs until they can be processed.
- Queue workers execute queued jobs.
- Use
ShouldQueuefor jobs that should run asynchronously. - Dispatch jobs using
JobName::dispatch(). - Use delays for tasks that should execute later.
- Use retries for temporary failures.
- Monitor failed jobs in production.
- Keep jobs small and focused.
- Pass IDs instead of unnecessarily large objects.
- Design important jobs to handle retries safely.
- Use dedicated queues for different priorities.
- Redis and Laravel Horizon are powerful options for larger queue workloads.
- Use process management to keep production queue workers running reliably.
