Laravel scheduler not running: find the cause, then let Laravel's ping hooks report every run

There is no cron entry, or it is not every minute

Laravel runs nothing by itself. One cron entry must call schedule:run every minute, and that command decides which tasks are due. The entry from Laravel's documentation sends all output to /dev/null, so while you debug, point it at a log file instead.

* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1

Cron cannot find php, or runs as someone else

Cron starts jobs with a minimal environment, so a php that works in your shell may not be on cron's PATH. Use the full path from which php, and install the entry in the crontab of the user that runs the application. The cron job not running guide covers the PATH and environment causes in detail.

The schedule is defined where Laravel does not read it

In current Laravel versions the schedule lives in routes/console.php, or in a withSchedule closure in bootstrap/app.php. An example written for app/Console/Kernel.php, copied into an application that has no such file, registers nothing. php artisan schedule:list shows exactly what is registered and when each task is next due.

The application is in maintenance mode

Laravel's documentation: "Your application's scheduled tasks will not run when the application is in maintenance mode." A deploy that fails between php artisan down and php artisan up therefore skips every task until someone notices. Tasks that must run anyway take evenInMaintenanceMode().

The scheduler is paused

In Laravel 13, php artisan schedule:pause stops all scheduled task processing without a code change, and nothing runs until php artisan schedule:continue. A task marked evenWhenPaused() still runs.

An old overlap lock is still held

withoutOverlapping() takes a lock in your application's cache, and by default the lock expires after 24 hours. If a server dies mid-run, the task is skipped until the lock expires. php artisan schedule:clear-cache clears these locks; the documentation describes it as "typically only necessary if a task becomes stuck due to an unexpected server problem."

A long task holds up the ones after it

"By default, multiple tasks scheduled at the same time will execute sequentially based on the order they are defined." A slow task makes every later one start late. runInBackground() runs a command or exec task in the background so they can run at the same time.

A timezone with daylight saving

timezone() on a task, or schedule_timezone in the app configuration, makes the times local. The documentation warns: "When daylight saving time changes occur, your scheduled task may run twice or even not run at all", and recommends avoiding timezone scheduling where possible. The cron expression explainer shows which runs a change skips or repeats.

In a container, nothing runs the scheduler

A container runs only the process it was started with, so a crontab inside it does nothing unless a cron daemon runs there too. Laravel presents php artisan schedule:work for local development: it runs in the foreground and invokes the scheduler every minute until it is stopped. Whatever starts the scheduler in a container has to keep it running; if that process exits, no task runs and nothing reports it.

Create a monitor with the task's schedule

In the console, create a monitor with the task's cron expression (schedule:list prints it), in the timezone the task runs in, plus a grace window. Copy the ping URL into your configuration:

// config/services.php
'lastping' => [
    'nightly_etl' => env('LASTPING_NIGHTLY_ETL_URL'),
],

# .env
LASTPING_NIGHTLY_ETL_URL=https://ping.lastping.dev/<your-monitor-id>

Chain the ping hooks onto the task

Three of Laravel's built-in hooks, no package:

// routes/console.php
use Illuminate\Support\Facades\Schedule;

$ping = config('services.lastping.nightly_etl');

Schedule::command('app:nightly-etl')
    ->dailyAt('03:00')
    ->pingBefore("$ping/start")     // run started
    ->pingOnSuccess($ping)          // exit code 0
    ->pingOnFailure("$ping/fail");  // non-zero exit code

• pingBefore calls /start: the run began, which arms overrun detection for a task that hangs.
• pingOnSuccess calls the monitor URL when the command exits with code 0.
• pingOnFailure calls /fail when it exits non-zero, and the alert goes out at once.

Leave thenPing for the success URL out

thenPing pings after the task whatever its result, so pointed at the success URL it would report a failed run as a success. pingOnSuccess and pingOnFailure follow the exit code. Each ping is a plain GET request, which LastPing accepts, and a ping that cannot be delivered is reported to Laravel's exception handler without stopping the task.