Laravel Schedule List Laravel Package

Getting Started

Install and verify in three steps:

composer require hmazter/laravel-schedule-list
php artisan schedule:list --help   # confirm flags on your installed version
php artisan schedule:list

• Auto-discovery: Laravel 5.5+ picks up Hmazter\LaravelScheduleList\ScheduleListServiceProvider automatically. If the command doesn't appear, run php artisan package:discover (or composer dump-autoload) and check bootstrap/cache/packages.php.
• Where to look first: the command is a thin wrapper around Illuminate\Console\Scheduling\Schedule. Everything it shows comes from app/Console/Kernel.php::schedule() (and anything loaded into it). If a task is missing from the list, the problem is in the kernel, not the package.
• First use case: after adding or refactoring scheduled tasks, run schedule:list and read the Expression + Next Due columns side by side. That single view answers "did my ->dailyAt('03:00') actually register, and when will it next fire?" — which is otherwise tedious to check by hand.

The output is a table of task, cron expression, next-due timestamp, and description. Treat it as a read-only diagnostic, not a control surface.

Implementation Patterns

Audit as part of the task-definition loop. The list only reflects the kernel, so the fastest workflow is: edit schedule(), run schedule:list, confirm the task and its next run. Add ->description('...') to every task — descriptions are the primary way to make the output legible once you have more than a handful of entries:

$schedule->command('reports:generate')->dailyAt('02:00')->description('Nightly report build');
$schedule->command('cache:prune-stale-tags')->hourly();

Use JSON output in scripted checks. The package supports machine-readable output (verify the exact flag with --help on your version — typically --json). That makes it useful in CI or a monitoring probe:

php artisan schedule:list --json | jq -r '.[].command'

A common pattern is a deploy-time smoke test that asserts an expected command is present, or a nightly check that alerts if a critical task vanished from the schedule.

Call it programmatically from an ops dashboard or custom command when you want the schedule rendered in-app:

Artisan::call('schedule:list');
$output = Artisan::output();

Use it to reason about environments. Because the list is generated from the resolved kernel, running it per-environment (local, staging, production) is a quick way to confirm conditional task registration (e.g. if (app()->isProduction()) { ... }) behaves as intended.

Pair with schedule:run debugging. When a task "isn't running," schedule:list rules out registration/expression problems first, so you can move on to withoutOverlapping locks, onOneServer, mutexes, and the system crontab.

Gotchas and Tips

• Laravel 9+ ships this built in. php artisan schedule:list is native from Laravel 9 onward. On modern Laravel this package is redundant — prefer the framework command, which is actively maintained. Only reach for this package on older versions where it adds genuine value.
• Last release was 2020-12-02. Treat Laravel 9/10/11 compatibility as unverified. Check the service provider against your framework version before adopting; if it breaks, forking the single command class is usually cheaper than waiting for an update.
• Empty or partial output almost always means a kernel problem. The list is populated by booting the console kernel; if a service provider throws before schedule() runs, tasks silently disappear. Run php artisan schedule:list -v and check logs if the list looks short.
• It only knows the scheduler, not cron. It shows tasks registered with Laravel's Schedule, not the crontab entry that invokes schedule:run, and not tasks scheduled by other mechanisms. It also won't surface withoutOverlapping(), onOneServer(), runInBackground(), or environments() constraints — those affect execution but aren't in the table.
• Closures and call() tasks are less informative. Tasks defined with a closure often render without a useful command string; give them descriptions so they're distinguishable.
• Timezone matters for "Next Due". The next-run calculation uses the app timezone (config/app.php) and, per-task, ->timezone(...). A mismatch between app timezone, task timezone, and the server's cron timezone explains most "it says 02:00 but runs at 07:00" confusion. Verify with a known expression and cross-check against the server clock.
• No meaningful extension points. It's a thin, single-command package with no plugin surface. If you need custom columns or filtering, copy the command into your app and register it yourself — the logic is small.
• Don't wire it into production HTTP routes without thought; like any artisan output endpoint it can leak operational detail. Keep it CLI-only, or gate it behind auth/can: middleware if you expose it.