Nova Scheduled Jobs Laravel Package

Technical Evaluation

Bottom line: A single-purpose, read-only Laravel Nova tool that surfaces the application's registered scheduled jobs — command/closure descriptions, cron expressions, timezones, and next-run times — inside the admin panel. No migrations, no write path, no queue interaction, no external service. Adoption cost is roughly a day of engineering including the compatibility spike. The actual decision is whether a low-adoption, single-maintainer dependency belongs on your admin surface, and the answer is yes only as internal convenience tooling with a pinned version and a known exit path.

Architecture fit

• Only fits estates already running Laravel Nova. The package is MIT and free; total cost of ownership is dominated by the Nova license you already pay per site.
• Integration surface is a Nova Tool registered in NovaServiceProvider::tools(). It resolves Laravel's Schedule singleton and renders the event collection. There is no persistence layer, no event listener, and no queue interaction.
• Natural home is a platform/ops team that already treats Nova as an internal control panel and wants scheduler visibility adjacent to existing resources rather than in a terminal.
• Poor fit for API-only apps, non-Nova apps, multi-framework estates, or teams standardizing entirely on external observability (Datadog, Sentry Cron Monitoring, healthcheck pings). Without the Nova integration this is a thin rendering of Schedule::events() and not worth adopting as a dependency.

Integration feasibility

• Two-step install: composer require llaski/nova-scheduled-jobs, then register the tool in NovaServiceProvider::tools(). Optional config publish. No artisan migrate step, no seeding, no service provider gymnastics.
• Feasible and low-effort on the Laravel 8–10 / Nova 4 combination the 6.1.x line targets. The most recent tag (6.1.3, 2023-08-16) is housekeeping — a PR-review action and dependabot config — not a compatibility expansion.
• Blast radius is genuinely small: no database changes, no request lifecycle hooks outside Nova, no writes. Backing it out is deleting one line from tools() and running composer remove.

Technical risk

• Maintenance risk is the dominant risk. 54 stars, zero dependents, a single maintainer, and no tagged release since August 2023. That is a convenience project, not infrastructure. Treat any future Nova or Laravel major as a potential break with no upstream fix.
• Framework-version risk. Laravel 11+ moved scheduler registration into routes/console.php / bootstrap/app.php, and the schedule loads during console bootstrap. If the web request does not load the schedule, the Nova page renders empty — a confusing failure that looks like a package bug. Compatibility with Laravel 11+ and Nova 5 is explicitly unverified in the available material.
• Authorization risk. The route sits behind Nova's auth middleware but is visible to every Nova user by default. Cron internals — job names, cadence, timezones — are disclosure you must gate deliberately with canSee() or a Nova policy. This is a configuration responsibility, not a package defect, but it will be missed if nobody owns it.
• Correctness risk from registration context. The package only sees jobs registered in the context the Nova web request boots in. Duplicated Schedule:: calls across providers produce duplicate rows that read as a bug; jobs registered only in console context silently vanish from the page.
• Silent scope gap. The tool does not surface withoutOverlapping(), onOneServer(), or runInBackground() flags, so a mutex-guarded job looks identical to an unguarded one. It also has no execution history. Teams that assume the panel answers "did it run?" will be wrong, and that misread is the most likely source of an incident narrative.

Key questions

• Are we on Nova today, and which Nova and Laravel majors exactly? If the answer is Laravel 11+/Nova 5, this becomes a spike with an explicit pass/fail gate, not an install.
• Does php artisan schedule:list match the Nova page on our actual stack, in staging, on the first deploy? Any divergence is a registration-context problem we must resolve before rollout.
• Who owns canSee() gating, and is admin-only the right default for our Nova user population?
• Are we prepared to pin the version, test on every Nova/Laravel upgrade, and fork if upstream goes stale? Forking is small and contained — the data is just the scheduler's event collection — but somebody must be named as owner.
• Is there an existing or planned investment in real scheduler monitoring? If yes, this is a stopgap and should be scoped as such; if no, this closes a visibility gap cheaply without pretending to be alerting.

Integration Approach

Stack fit

• Required: a Laravel application with Nova installed, scheduler jobs defined in app/Console/Kernel.php (Laravel ≤10) or routes/console.php / bootstrap/app.php (Laravel 11+) following the Laravel convention.
• Fits cleanly alongside Horizon, Telescope, and failed-job tables — it occupies the one slot those leave empty, which is scheduler registration metadata. It does not overlap or conflict with them.
• Does not fit if Nova is absent, if the team standardizes on an external observability vendor, or if the requirement is multi-service / multi-tenant / cross-environment visibility. Retrofitting into those shapes costs more than starting with a real tool.

Migration path

• There is no data migration. "Migration" here means adoption and, if needed, exit.
• Adoption: install the package, register the tool, gate visibility, verify the page against schedule:list, add the page to the deploy runbook.
• Prerequisite cleanup, which is real work and should be sequenced first: name every closure with ->name() and optionally ->description() (unnamed closures render as anonymous rows), consolidate the schedule into a single source of truth so duplicate rows do not appear, and annotate operational behavior — overlap guards, single-server constraints — in ->description() since the package will not surface those flags for you.
• Exit: remove the tool registration, composer remove. If the project goes stale mid-life, fork; the component is a read-only Vue table over the scheduler's event collection, which is a contained port.

Compatibility

• Verify composer.json at the installed tag for the laravel/nova and illuminate/* constraints before committing. Do not infer compatibility from the description.
• Laravel 11+/Nova 5: unverified. The failure mode is an empty page when the schedule is not loaded during web requests. Detect by comparing against php artisan schedule:list; remediate by ensuring definitions live somewhere that boots on every request.
• Timezone handling can disagree with app.timezone when a job sets ->timezone(...). Validate against schedule:list and the server clock rather than filing upstream bugs.

Sequencing

1. Spike (staging, timeboxed). Install at a pinned tag, register the tool, compare the rendered page against php artisan schedule:list job-for-job. Explicit pass/fail. If we are on Laravel 11+/Nova 5, this step decides go/no-go.
2. Schedule hygiene. Name closures, deduplicate registration, move the schedule to a single source of truth, add operational annotations to descriptions. This is the work that determines whether the page is useful or noisy.
3. Access control. Apply canSee() or a Nova policy, admin-only by default. Also decide per-environment registration — skipping it on staging or customer-facing dashboards where it is clutter.
4. Runbook integration. Add "verify the Scheduled Jobs page after deploy" to the release checklist. This is where the package earns its keep: catching jobs whose registration silently moved between Kernel.php, a provider, and routes/console.php, or whose cron expression drifted.
5. Rollout and communicate scope. Brief support and ops on what the panel answers (is it registered, when does it next run) and what it does not (did it succeed). Route failure questions to Horizon, error tracking, or the monitoring tool.
6. Exit readiness. Document the fork path and name an owner. Re-evaluate at every Nova or Laravel major.

Operational Impact

Maintenance

• Nominal ongoing maintenance is near zero: no database, no cron of its own, no external calls, no background processes. The package is a read-only rendering layer.
• Real maintenance is the upgrade tax: pinning the version and validating the page on every Nova and Laravel upgrade. Budget a few hours per major upgrade for the staging check, plus the possibility of a fork.
• Bus factor is one. Single maintainer, no release since August 2023, zero dependents. There is no community to absorb a break. This is the primary reason to cap the package's roadmap weight at "internal accelerator."

Support

• The operational win is interrupt reduction: support and ops answer routine "is the nightly job still scheduled, and when does it next run?" questions from the admin panel instead of paging an engineer or SSHing into a host.
• That win depends on a briefing, not just an install. If support believes the page reports success/failure, the reduction flips into mis-escalation. Scope the tool explicitly in the handover: registration-time metadata only.
• Escalation path stays as-is for actual failures — Horizon, error tracking, scheduler monitors. This package never becomes the system of record for whether a job ran.

Scaling

• Scales with Nova, not with job volume or traffic. The page reads an in-memory event collection at request time; there is no index to grow and no write amplification.
• Single application, single scheduler is the supported shape. Multi-tenant, multi-service, and cross-environment visibility are out of scope and should be met with dedicated observability tooling rather than an extension of this panel.
• For run history, exit codes, or runtime metrics, the correct move is a separate Nova card or metric backed by your own schedule_runs table — not extending this tool. Extension points are shallow by design.

Failure modes

• Empty page on Laravel 11+ when the schedule is not loaded during web requests. Diagnose with schedule:list; fix by relocating schedule definitions.
• Duplicate rows from repeated Schedule:: registration across providers. Diagnose by grepping app/, package service providers, and routes/console.php.
• Anonymous closures rendering as opaque rows. Fix the schedule with ->name() / ->description(), not the package.
• Timezone drift between computed next-run times and app.timezone for jobs with explicit ->timezone().
• False confidence — the highest-severity failure mode. A green-looking panel that shows a job registered says nothing about whether it succeeded, whether a mutex blocked it, or whether it ran on the wrong server. Mitigate with documentation and by keeping the runbook pointing at real monitoring.
• Overexposure to all Nova users by default if canSee() is not configured.
• Upgrade break with no upstream fix after a Nova or Laravel major. Mitigate with pinning and the fork path.

Ramp-up

• Engineering: under a day end-to-end on a compatible stack, including the staging verification and the schedule-hygiene pass. The install itself is minutes; the naming and deduplication work is the bulk and has independent value.
• Support and ops: a short briefing, not training. Two questions the page answers, two it does not.
• Organizational: the meaningful ramp-up cost is governance — agreeing that this is convenience tooling, not an SLA-bearing dependency, and assigning an owner for upgrades and the eventual fork decision. That agreement, not the code, is what keeps the risk contained.