rrr/nova-schedule-list
A Laravel Nova card that surfaces your application's scheduled tasks in a simple list, making cron commands and their timings visible from the Nova dashboard. Useful for quickly checking what runs, how often, and when—without opening a terminal or logging into the server.
This is a micro-package (1 star, 0 dependents) whose apparent purpose is to surface Laravel's scheduled tasks — the output of php artisan schedule:list — inside Nova, typically as a card on the dashboard or a tool in the sidebar. Treat it as a convenience UI wrapper, not infrastructure.
Minimal steps:
composer require rrr/nova-schedule-list (there is no Packagist signal at this score, so confirm the vendor/name resolves; otherwise add the GitHub repo as a VCS repository in composer.json).cards() array in app/Nova/Dashboards/Main.php. For a tool: add it to tools() in app/Providers/NovaServiceProvider.php. Check src/ and the README for the exact class name — with a package this small, reading the source is faster than reading docs.php artisan nova:publish --force (only if it ships assets), then php artisan optimize:clear.Where to look first:
composer.json — confirm the Nova version constraint (laravel/nova is typically ^4.0 or ^5.0) and PHP requirement. This is the single biggest compatibility gate.src/ — likely one Card or Tool class plus a Vue component in resources/js. That tells you exactly what it renders and which endpoint it calls.component() method — this is the Vue component name; match it against resources/js/components.First meaningful use case: drop the card on the main dashboard so on-call engineers can eyeball upcoming and recently-run scheduled jobs without SSHing into a box or opening a terminal. That's the whole value proposition — a read-only window into the scheduler.
Dashboard card (most common). Add the card to a dashboard's cards() method. If the package exposes a canSee() or a constructor taking a schedule name filter, use it to scope visibility per team.
Per-environment gating. Scheduler contents differ between staging and production. Wrap registration in a check so the card only appears where it's meaningful:
public function cards(): array
{
return [
// ...
...(app()->environment('production') ? [new ScheduleListCard()] : []),
];
}
Or, better, implement canSee() on a thin subclass so authorization stays in one place rather than scattered across dashboard definitions.
Tool registration for a dedicated page. If the package ships a Tool rather than a Card, register it in NovaServiceProvider::tools() and it gets a sidebar entry and its own route. This is preferable when the list is long and you want it linkable (/nova/schedule-list) for runbooks and alerts.
Pairing with monitoring. The card is a view, not an alerting system. The day-to-day pattern is: keep the card for human inspection, and run php artisan schedule:list --json (Laravel 10.2+) in your own health-check or uptime monitor for machine-readable output. Don't ask this package to be your scheduler's watchdog.
Filtering / customizing the list. If the underlying implementation shells out to schedule:list, you can influence what appears by conditionally registering commands in bootstrap/app.php (Laravel 11) or app/Console/Kernel.php (Laravel ≤10) — e.g. ->environments('production'). The card reflects whatever the scheduler knows, so controlling registration upstream is the cleanest "configuration."
This package is a maintenance risk. One star, zero dependents, score ~0.005. Assume no future updates. Before adopting, read every line of src/ — it's small enough — and be prepared to vendor it into app/ if it breaks. Pin the exact version in composer.json and commit composer.lock.
Version drift is the real hazard. Laravel changed schedule:list output (and added --json) around 10.x; Nova 4→5 changed tool/card bootstrapping. If the package parses command output with a regex, a minor Laravel bump can silently blank the card. Verify by running php artisan schedule:list manually and comparing to what the card shows — divergence points straight at a parsing bug.
Shell execution and permissions. If the card invokes Artisan via Process/exec, the web user (e.g. www-data, or the PHP-FPM user) must be able to run PHP and reach the app root. Failures here surface as an empty list or a 500 in the card, not a friendly error. Test from the CLI as the web user: sudo -u www-data php artisan schedule:list.
Timezones and "next run" math. Scheduler display depends on config/app.php timezone and each task's ->timezone(). A card that renders "next run" in UTC while your team reads local time is a recurring source of confusion. Sanity-check against php artisan schedule:list in the same TZ.
Queue and schedule:run are separate concerns. Seeing a task in the list does not mean it fired. If a job is ->onOneServer() or queued, the card won't tell you whether the worker is alive. Pair it with queue:monitor / Horizon for the full picture.
Extension points are thin. Expect at most: a published config, a Vue component you can override via nova-components publishing, and possibly a canSee() hook. There's unlikely to be an event system or repository pattern to hook into. Design your integration so the card is removable — keep any real logic in your own Artisan commands and treat the card as pure presentation.
Debugging checklist when the card is blank or errors:
php artisan schedule:list in the CLI — does the scheduler itself have entries?storage/logs/laravel.log and storage/logs/nova.log for exceptions from the card's controller.public/vendor/ assets — a missing asset yields a silent blank card, not an error.Nova::version() against the package's composer.json constraint.Have an exit plan. If the package stops working, replacing it is trivial: a custom Nova card (or even a simple Blade view behind a Nova route) that runs Artisan::call('schedule:list') and renders a table gets you 90% of the value in an afternoon. Budget for that rather than depending on upstream fixes that will not come.
How can I help you explore Laravel packages today?