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.
Architecture fit. Based on package scope and naming, rrr/nova-schedule-list is a Laravel Nova presentation-layer add-on that surfaces the application's registered scheduler events (the contents of Illuminate\Console\Scheduling\Schedule::events()) inside the Nova admin panel — cron expression, command/closure, next due run, and likely onOneServer / withoutOverlapping flags. Architecturally this is the cheapest possible kind of dependency: read-only, no migrations, no Eloquent models, no queue or event hooks, no persistence. It does not touch the request lifecycle outside Nova routes and does not alter scheduling behavior. That means the blast radius of adoption is confined to one admin screen — a meaningful de-risking factor that offsets the package's otherwise poor health signals.
Integration feasibility. Mechanically trivial for a team already running Nova: a composer require, then registering a card in NovaServiceProvider::cards() or a tool in tools(). Realistic effort is half a day including staging verification. The gating item is not this package at all — it is the Nova license and composer.nova.laravel.com credentials, plus confirming the package's composer.json constraints against your Nova major version (4.x vs 5.x) and PHP version (8.1–8.3). With 1 star and 0 dependents, assume zero prior validation and treat the source as unreviewed code entering your admin panel.
Technical risk. Split this cleanly: runtime risk is low (read-only, no data, no auth surface of its own — Nova's middleware governs access), while sustainability and supply-chain risk is high. One star and zero dependents means no peer review, no downstream bug reports, no CVE watch, and no evidence the maintainer responds to issues. A package that renders inside an authenticated admin panel is still a code-execution surface; review src/ before install rather than trusting the MIT license as a safety signal.
Key questions for the maintainer (or for your own source review).
Schedule instance per request, or shell out to schedule:list? The former is cheap; the latter has subprocess and path assumptions.onOneServer(), cache locks, and the fact that "last run" is not knowable from code alone?composer.json, and are constraints ranged or pinned?->timezone() and ->description()?Stack fit. Requires Laravel + laravel/nova (paid, per-site license) + PHP 8.x. If the team is not already a Nova shop, this package is not a reason to become one — the $99–$199/site license plus private-repo plumbing dwarfs the value of a scheduler listing screen.
Migration path. The package is small and non-load-bearing, which makes the fallback path unusually cheap: if it is incompatible or unmaintained, reimplementing the equivalent as a first-party Nova card is roughly a one-day task (Schedule::events() → map to fields → render a table). Forking into app/Nova/Cards/ScheduleList.php also eliminates the third-party dependency entirely. Treat "vendor or rebuild" as a live option, not a last resort.
Compatibility. Pin the exact version, verify declared constraints against your Nova/PHP matrix, and run it in a throwaway Laravel app before touching a real project. Pay specific attention to Nova major-version churn — Nova's card/tool APIs have shifted between 4 and 5, and a 1-star package is unlikely to have tracked that.
Sequencing.
src/ and composer.json — confirm read-only behavior and version ranges.onOneServer and one withoutOverlapping entry).Maintenance. Effectively unmaintained as a dependency: assume no upstream fixes, no security patches, and no compatibility updates for future Nova/PHP releases. Budget an internal owner and a documented fork point. The upside is that the surface is tiny — a vendored copy is a low-cost thing to own.
Support. Community-only, no SLA, no vendor relationship. Escalation path is "read the source," which is viable here precisely because the package is small. Do not adopt if the team lacks Laravel-internals fluency.
Scaling. Negligible at runtime — it is an admin-panel read with no write path and no per-request cost on user-facing traffic. The two scaling caveats are (a) rendering hundreds of schedule entries with repeated cron evaluation on every card load, and (b) correctness, not performance, in multi-server deployments: the schedule is defined in code so the list is consistent across nodes, but actual execution state (last run, success/failure, lock ownership) is not derivable from the Schedule object. If operators need real execution truth, this package is the wrong tool — that is a job for scheduler monitoring/log aggregation.
Failure modes.
Ramp-up. Hours for any Laravel developer familiar with Nova. No new concepts, no data model to learn, no runbook beyond "it's a read-only screen."
TPM recommendation. Low strategic value, low integration cost, high sustainability risk, and the underlying user need (php artisan schedule:list without SSH) is already served by native Laravel tooling and mature observability products. Adopt only as a vendored, internally-owned Nova card in a team already standardized on Nova — not as a Composer dependency you expect anyone else to maintain.
How can I help you explore Laravel packages today?