Laravel scheduled tasks not running: what I check first

If a Laravel dashboard still opens but the morning report never arrives, a stock sync stops updating or an overnight import is missing, I would start by tracing the scheduled work. A working website does not establish that the background process ran.

When investigating Laravel scheduled tasks not running, I separate the server trigger, the application's schedule and the work the task is meant to perform. That gives me a way to locate the failure before changing cron entries or rerunning a batch that might already be partly complete.

Start with one missed task and its expected result

I would ask for the task's name, when it should have run, the last known successful result and what changed around that time. An expected timestamp is more useful than “the automation is broken”. I also want to know what success looks like: a file in storage, updated records, a delivered report or an acknowledged response from another system.

For example, if a daily stock import normally updates a particular supplier's products, I would compare the source file's timestamp with the last recorded import and a small sample of affected products.

Before a rerun, I would establish whether the task sends messages, creates documents or changes external records. Where there is a risk of duplicate work, I want to understand the task's record of what has already been processed.

Check whether the Laravel task is actually scheduled

php artisan schedule:list lists scheduled tasks and their next due times. I would run it from the deployed application directory with the intended PHP executable, then compare the output with the task the business expects.

If the task is absent, I would inspect the deployed release rather than assume a server cron problem. Was its definition committed? Is this the current application directory? Does the deployed version include the command or job? A screenshot from a developer's laptop cannot answer those production questions.

I would also check its frequency, timezone and constraints. Environment filters, conditional rules and maintenance mode can prevent a scheduled task from running. Commands and scheduler features vary by framework version; use the Laravel scheduling documentation that matches the application.

Laravel cron job not running: verify the server trigger

The standard Laravel scheduler setup invokes php artisan schedule:run every minute through cron or a hosting scheduler. It evaluates which tasks are due.

I would verify the configured command, application path, account and PHP executable. A hosting migration or a release-directory change can leave an old path in a control panel. I would compare the scheduled environment with the working SSH environment, including available PHP extensions and access to the application's required files.

Next, I would look for evidence of the trigger actually running. Where does the host record its execution? Is useful output being captured? What happened at the expected time? If everything is discarded, I would arrange a temporary, private diagnostic log with a sensible retention period.

Running schedule:run manually can perform real due work. I would inspect the task's effects before using it as a test. I would also check for an existing trigger before adding another one; a second cron entry can make diagnosis harder and create duplicate work.

Is a business process missing its daily run?Tell me which report, import or sync is overdue, when it last worked and whether anything was deployed or moved. I can help trace the failure and scope the repair.
Talk to Adam about Laravel support

The scheduler may run while a queued job stays unfinished

A scheduled task can dispatch a job to a queue rather than do all its work immediately. In that setup, successful dispatch still leaves a separate worker responsible for processing it.

I would identify the actual queue connection and queue name, then check that the worker is listening to those destinations. A worker process existing somewhere on the server is not enough. It needs to belong to this application and consume the work this task creates.

I would inspect pending work, failed jobs and application logs around the expected run. Then I would follow one execution through to its result. That helps distinguish a job that never started from a job that ran and failed while writing a file or calling an external service.

Laravel's long-running queue workers need to reload after code changes. The official queue deployment guidance explains graceful restarts and process supervision. I would check how this application's deployment handles that, rather than restart unrelated services on a shared server.

For that part of the investigation, my Laravel queue troubleshooting article covers the worker checks in more detail.

Check locks and deployment state before clearing anything

Tasks using withoutOverlapping use cache locks to prevent concurrent runs. If a run appears stuck, I would establish whether it is still active before considering a stale-lock cleanup. Multiple-server setups also need a deliberate plan for which server executes each task.

Clearing all application caches is not my first diagnostic step. I want to understand what the cache contains and which process owns the work. Removing a safeguard while an import is still running could allow a second execution to compete with it.

I would review the deployment record too: the active release, dependency installation, configured environment and treatment of cached configuration. Laravel's deployment documentation explains configuration caching. Editing an environment file alone is not evidence that a deployed process is using the intended configuration.

For sub-minute schedules, a running scheduler can continue using the previous release until the minute finishes. Laravel documents schedule:interrupt for use after deployment. I would check whether that behaviour is relevant to this application's schedule, rather than add it to an unrelated setup.

Confirm the business result, not just a successful command

Once the cause is understood, I would plan a controlled test and verify the intended outcome. An import should update the right records. A generated report should contain the expected period. An external sync should have a usable acknowledgement or reconciliation record.

I would then observe the next scheduled run without manually triggering it. Otherwise, we have demonstrated that the task can run, but not that the normal scheduling path is working again.

A useful ongoing check records the last successful completion and alerts when the next expected result is overdue. It should identify the process and the consequence, so the person receiving the alert knows whether they are looking at a missing report or a stale stock feed. Keep sensitive payloads out of routine alerts.

What I need to investigate an inherited Laravel application

You do not need to arrive with the diagnosis. A short description of the business process, its expected timing, the last successful run and any recent deployment or hosting change gives me a starting point. Please leave credentials and customer data out of the initial enquiry.

My Laravel development and ongoing support work includes inherited codebase reviews, unreliable jobs, integration maintenance and application improvements. For recurring problems, I would agree a stabilisation plan and an appropriate support arrangement after understanding the system.

Get the background work back under control.If missed scheduled tasks are holding up your business, send me the symptom and the process it affects. We can establish what needs fixing and what should be monitored afterwards.
Discuss your Laravel applicationSee development pricing