- What does hmazter/laravel-schedule-list actually do?
- It is a single-purpose diagnostic package that introspects the events registered with Laravel's scheduler and renders them as a table, so you can see what is actually queued up rather than grepping app/Console/Kernel.php. The overview also describes a web page alongside the artisan command for the same inventory. There is no persistence, no configuration surface, and no coupling to your domain code, which makes it a very low-risk read-only tool. Its value is answering the question 'what is registered with the scheduler right now' during debugging or on-call triage.
- How do I install hmazter/laravel-schedule-list?
- Run composer require hmazter/laravel-schedule-list and the service provider is picked up automatically via Laravel package auto-discovery. There are no migrations, no env changes, and no config file to publish. A spike on a known-good Laravel and PHP version pair should take well under an hour.
- Does hmazter/laravel-schedule-list support Laravel 9, 10, or 11?
- Treat it as a legacy-only candidate. The last release was December 2020, which predates Laravel 9, 10, and 11 as well as PHP 8.1+ and Symfony Console 6, so the illuminate/* and symfony/console constraints are likely to conflict. Validate per application with composer why-not hmazter/laravel-schedule-list against your pinned PHP and framework versions before adding it. On modern Laravel you almost certainly do not need it at all.
- Doesn't Laravel already have a schedule:list command?
- Yes. Laravel shipped a native schedule:list command in 8.37+, so on any application at or above that version this package is either redundant or a command-name collision, which is a confusing failure for the exact engineers who run it during an incident. The package's value is confined to apps pinned below 8.37, or to cases where its output is materially richer than the native command. Verify that claim side by side before assuming it.
- Should I install it with require-dev or as a production dependency?
- Prefer require-dev so the deploy artifact and production dependency graph stay clean. The exception is if your runbooks or incident response genuinely need the command available in production, in which case accept the extra dependency and document why it is there. Since it is a local CLI diagnostic with no external input, the runtime risk is negligible either way.
- Which scheduled tasks might it miss or render inaccurately?
- The highest-severity failure mode for any schedule inventory is silently omitting entries, and closure-based schedules registered with Schedule::call, custom event classes, sub-minute frequencies, and runtime-conditional registration are the cases a parser like this is most likely to under-report. It may also mis-render cron expressions, timezone, or constraint metadata. An inventory tool that quietly drops entries is worse than no tool, so cross-check its output against the native command and your kernel source.
- Is hmazter/laravel-schedule-list safe to run in production?
- The security surface is effectively nil: it is a local CLI command with no external input, no network calls, and no filesystem writes. The real risks are obsolescence and misleading output rather than exploitation. A stale dependency in composer.lock can also become an audit finding and block a framework upgrade if its constraints conflict.
- Is hmazter/laravel-schedule-list still maintained?
- The last tagged release is from December 2020 and there is no sign of recent activity, so assume it is dormant. Plan for the possibility that you own the fork if the upstream maintainer stays inactive. The logic is thin enough that a small internal command or an org-owned fork pinned to a commit is often cheaper than carrying dependency risk.
- What are the alternatives to hmazter/laravel-schedule-list?
- On Laravel 8.37 and above, the framework's native schedule:list is the correct default and requires no extra dependency. Where you still need richer output such as next-run times, human-readable cron, or overlap state, a 50 to 150 line internal artisan command covering your exact scheduling patterns is usually the highest-leverage path. Forking the package under your own organization and pinning it to a commit is the other realistic option.
- How do I test or verify the package's output before trusting it?
- Install it in a staging environment, run the command, and compare the table row by row against php artisan schedule:list and your console kernel registrations. Pay particular attention to closure schedules, custom events, sub-minute tasks, and anything registered conditionally at runtime. Also confirm the cron expressions and next run times match what the scheduler reports natively. If anything is missing, treat the tool as unreliable for that application.