Laravel queue not working? How I investigate stuck emails and imports

Your Laravel application loads, customers can log in, and the dashboard looks normal. Meanwhile, confirmation emails are missing, a CSV import has been processing since yesterday, or records have stopped reaching another system.

When someone asks me why their Laravel queue is not working, I start with one affected task. I want to know what triggered it, what should have happened, and the last point where there is evidence that it worked. A working homepage tells me very little about the background work your business depends on.

First, separate the symptom from the cause

“Emails are broken” is a useful report from a customer. It is not yet a diagnosis. The application might never have requested the email, the job might be waiting, processing might have failed, or the message might have reached the mail provider without reaching the inbox.

I ask for one example, its approximate time and the expected result. An import reference or an internal record ID is more useful than repeatedly clicking the same button. If the task creates invoices, sends customer messages or updates stock, repeated attempts can also make the eventual clean-up harder.

• Nothing was created: investigate the action that should have started the work.
• Work is waiting: investigate what is meant to process it.
• Work failed: read the error and identify the affected records.
• Work completed but the result is missing: follow the next system in the chain.

Check the queue connection and the queue name

Laravel distinguishes the queue connection, such as database or Redis, from a named queue within it. A worker listening on one connection or queue will not consume jobs sent somewhere else. I compare the application's effective configuration with the actual worker command. Laravel explains this distinction in its queue documentation.

This is a particularly useful question after a hosting move or deployment: are we inspecting the application that customers use, and is its worker attached to the same environment? A process with the right name is not enough. I want the application path and the intended destination to agree.

No failed jobs does not mean everything is healthy

A task that has not run cannot report a processing failure. I check waiting work as well as failures, and compare the oldest outstanding task with the delay the business considers acceptable.

A report that arrives ten minutes late might be inconvenient. A password reset with the same delay can stop someone using the service. The useful monitoring threshold follows the task, rather than a single arbitrary number for the whole application.

For an initial investigation, I want a small set of evidence:

• The last successful example and the first known unsuccessful one.
• Whether the backlog is growing, shrinking or unchanged.
• Whether every background task is affected or only one type.
• Any deployment, hosting change or external service change near that time.

Why a queue can stop working after deployment

Laravel queue workers are long-lived processes. They need restarting during deployment to load changed application code. Laravel documents queue:restart and process supervision in its deployment guidance for workers.

I review the deployment procedure alongside the code change. Who starts the worker again? Is its status checked afterwards? Is there a small, observable background task that proves the new release works beyond the browser?

If the same fault returns after every release, manually recovering it each time is only an interruption to the pattern. The deployment needs a repeatable check, with an owner who knows what a healthy result looks like.

When Laravel emails are not sending

I separate successful job execution from successful email delivery. Provider acceptance and inbox arrival are different checkpoints. That prevents a queue investigation turning into hours of changing mail settings without evidence.

A useful test has a known recipient, a recognisable subject and a recorded time. I trace that single message through the application and the provider's delivery events. If the provider reports rejection or suppression, I investigate that result. If no request reached it, I work backwards.

I also ask whether an ordinary non-queued email works. That comparison can narrow the investigation, but it does not prove that the queued path is healthy.

Recover the backlog without repeating customer actions

Before replaying failed work, I establish whether an external action already succeeded. Laravel supports retrying failed jobs; the application still needs to handle repeated execution safely. See its failed-job retry documentation.

Imagine an accounting export that created a record externally, then lost the response. That is an illustrative scenario, not a client case study. Pressing retry without checking the external record could create a second record if the integration has no duplicate protection.

My recovery plan therefore includes reconciliation: which records are missing, which already exist, and which need a human decision? I prefer a small verified batch before releasing a substantial backlog. “The queue is empty” is not the same acceptance test as “the right work happened once”.

What I would want from a lasting fix

For a business-critical Laravel application, I would expect the investigation to leave more than a running process:

• A plain-English explanation of the failure and its business impact.
• A record of what was recovered and any exceptions still outstanding.
• A deployment check covering the affected background workflow.
• Monitoring for unacceptable delays as well as explicit failures.
• A short recovery procedure that the next developer can understand.

Those are the outcomes I would scope. The amount of work depends on the system and the evidence. Some faults are isolated configuration problems; others expose a fragile integration or an operational gap that needs more attention.

When to get Laravel support involved

If staff are manually checking exports, resending emails or watching an import screen every morning, the cost is already broader than a technical error. I can help investigate unreliable background jobs as part of my Laravel development and ongoing support.

You work directly with me, Adam. Start with what has stopped, when it last worked, and how it affects the business. You do not need to diagnose it before getting in touch, and you do not need to send passwords in an enquiry.

Background jobs holding up your business?Tell me what is stuck and what should happen. I can help scope the investigation and the next steps.
Discuss your Laravel issue with AdamView service pricing