Nova Scheduled Jobs Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. "Give us a scheduler view in the admin panel" is a recurring backlog ask that usually gets scoped as a custom Nova tool. This package is the off-the-shelf candidate: evaluate it in a short spike before anyone commits a sprint of engineering to build the same table. The decision is cheap to reverse — a two-step install with no migrations, no write path, and no background work.
• Observability roadmap for background work. Most Laravel teams instrument queues (Horizon, Telescope) but leave the scheduler invisible outside SSH and crontab -l — even though nightly invoices, exports, syncs, and cleanups run through it. This closes a known gap in the admin surface for roughly a day of effort, before we commit budget to paid APM or uptime tooling.
• Support and escalation workflow. A read-only "what is scheduled, and when does it next run" panel lets support and ops answer routine questions without paging an engineer. That is a measurable reduction in interrupt load, not just a nicer dashboard.
• Integrity of customer-facing scheduling claims. If the product or docs promise "your nightly sync runs at 02:00 UTC," engineering needs an authoritative internal view to keep that promise honest. This is a cheap source of truth for a commitment we already make publicly.
• Deploy and release readiness. Adding "verify the Scheduled Jobs page" to the release runbook catches jobs whose registration silently moved between Kernel.php, a service provider, and routes/console.php, or whose cron expression drifted — a class of incident that is otherwise found by a customer.
• Prioritization signal. Low stars (54), zero dependents, a single maintainer, and a last tagged release in August 2023 mark this as a convenience tool, not infrastructure. That should cap the roadmap weight it gets: an internal accelerator, not a dependency we plan a quarter around.

When to Consider This Package

Consider it when:

• We already run Laravel Nova in production. The integration is the entire value. Do not adopt Nova in order to get this.
• We have scheduled jobs in Laravel's scheduler and no view into them — the current answer is "SSH in and check" or "ask whoever set it up."
• Read-only inventory is the actual requirement. We need to confirm what is registered and when it next runs, not to be alerted when it fails.
• The scope is one application, one scheduler. Internal tooling, not a multi-service control plane.
• We can absorb the maintenance risk. Pin the version, read composer.json at the tag for the laravel/nova and illuminate/* constraints, test in staging on every Nova/Laravel upgrade, and keep a fork as the fallback. The underlying data is just the scheduler's event collection, so the fork is small and contained.
• We want a small, reversible commitment. Composer require plus one line in NovaServiceProvider::tools(). No schema, no listeners, no persistence — backing it out is trivial.

Look elsewhere — or build — when:

• We are not on Nova. Without the admin-panel integration this is a thin rendering of Schedule::events() we can write ourselves.
• We need failure detection, alerting, or run history. Use a dedicated scheduler monitor (Cronitor, healthcheck pings, Sentry Cron Monitoring) or error tracking. A page nobody watches is not monitoring.
• We need auditability, fine-grained RBAC, or compliance evidence around job execution. That is a platform decision, not a Nova panel. Note the tool is visible to every Nova user by default; it must be gated with canSee() or a Nova policy before it ships.
• We need multi-tenant, multi-service, or cross-environment visibility. Retrofitting this into that is more expensive than starting with a real observability tool.
• We target Laravel 11+ / Nova 5. Scheduler registration moved to routes/console.php / bootstrap/app.php, and the page can render empty if the schedule isn't loaded on web requests. Compatibility is unverified — treat it as a spike with an explicit pass/fail, not an assumption.
• The team has a standing policy against low-adoption, single-maintainer dependencies. Legitimate. Copy the approach as a reference implementation instead of installing it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a visibility gap in the scheduled work the product depends on — nightly jobs, syncs, and cleanups that nobody can see without an engineer logging into a server. This is a small, free, MIT-licensed add-on to an admin panel we already pay for, and it closes that gap for roughly a day of engineering effort instead of a sprint of custom build. The risk is low but real: it is a single-maintainer project with light adoption and no release since August 2023, so we would treat it as internal convenience tooling, pin the version, verify compatibility with our Nova and Laravel versions before committing, and never depend on it for anything customer-critical. Recommended decision: approve a short spike with an explicit pass/fail, ship it as an internal ops aid, and keep real failure alerting on the roadmap as a separate, funded item.

For engineering: This is a Nova tool that surfaces the Laravel scheduler inside the admin panel — registered jobs, cron expressions, descriptions, and next run times — so nobody has to SSH to answer "is the nightly job still scheduled?" It is strictly read-only: no schema, no write path, no background work, and it does not replace Horizon or alert on failure. Registration is one line in NovaServiceProvider::tools(); gate visibility with canSee() because it is exposed to all Nova users by default. Before we rely on it, prove it on our actual stack: check composer.json at the tag for Nova and illuminate/* constraints, and on Laravel 11+ confirm the schedule is loaded during web requests by comparing the page against php artisan schedule:list. Two things make the page useful rather than confusing: name every closure with ->name()/->description() (unnamed closures render opaque), and annotate operational behavior in the description, since withoutOverlapping(), onOneServer(), and runInBackground() are not surfaced. Treat it as a pinned dependency with a known exit path — if it goes stale or breaks on upgrade, forking is small and contained. Do not let it become load-bearing for anything with an SLA.