Product Decisions This Supports
- Ops visibility as a feature, not a ticket queue. The package surfaces Laravel's scheduled task list (
schedule:list) inside the Nova admin panel. The PM decision it informs: do we invest in in-product operational visibility for support, ops, and account managers, or do we keep that knowledge locked in engineering and SSH access? Every "did last night's sync/report/billing job run?" question routed to an engineer is a measurable support cost this class of tool can reduce.
- Build vs. buy for internal tooling. This is a thin Nova card wrapping framework-native introspection. The realistic decision is not "buy" — it's "adopt as a spike, then decide whether to own 150 lines of code." Use it to validate demand (do people actually open the card?) before committing roadmap capacity to a first-class ops dashboard.
- Roadmap sequencing for an internal-tooling epic. If you already run Nova, this is a candidate "day-one win" for an admin-experience epic: high demo value, low effort, no customer-facing risk. If you don't run Nova, this package is irrelevant and should not pull you toward adopting Nova.
- Buy-vs-build against monitoring vendors. It clarifies the boundary between visibility (this package: what is scheduled, when it last ran) and reliability (Healthchecks.io, Oh Dear, Sentry Crons, Spatie's schedule monitor: alerting, missed-run detection, history, multi-server correctness). PM decision: fund the monitoring subscription for anything revenue-critical; treat this as a convenience layer only.
- Vendor-risk triage. With 1 star and 0 dependents, adopting it is a deliberate "we will fork this" decision, not a dependency decision. That's a legitimate PM call for internal tooling — but it must be made explicitly rather than discovered during an upgrade.
When to Consider This Package
Consider it when all of the following hold:
- You are already running Laravel Nova (the package is worthless otherwise — it is a Nova UI component, not a standalone dashboard).
- Your scheduled jobs are conventionally defined in the Laravel scheduler and your team would benefit from reading that list without shell access.
- The audience is internal (support, ops, CS, junior engineers) and read-only visibility is sufficient — no alerting SLA, no audit trail requirement.
- You accept ownership: expect to fork, pin the version, and review the diff on every Nova/Laravel major upgrade. Assume the maintainer is unavailable.
- You are on, or can verify compatibility with, your Nova major version. Nova's licensing and version churn is the most common breakage vector for cards of this vintage; validate before it reaches a shared environment.
Look elsewhere (or build in-house) when:
- Reliability matters. A schedule list is not monitoring. It does not tell you a job silently failed to dispatch, ran twice across two app servers, or hung. For revenue-affecting jobs, this is the wrong tool — use a heartbeat/alerting service.
- You are not on Nova, or you're on Nova but deliberately minimizing third-party cards in the admin surface (a reasonable security and maintenance posture — Nova cards execute in an authenticated admin context).
- You need history, ownership metadata, or multi-tenant scoping (e.g., "which customer's job failed"). This package's scope stops at enumeration.
- Procurement or compliance review is required. MIT license is clean and permissive, but 1 star / 0 dependents / single maintainer will not survive a formal third-party risk assessment. If your process demands that, budget for a fork-and-own decision instead.
- You need it to work across multiple servers or queue workers — the list reflects the scheduler definition, not distributed execution state.
How to Pitch It (Stakeholders)
To executives: This is a small, free (MIT) admin-panel widget for teams already on Laravel Nova that shows which background jobs are scheduled and when they run — turning recurring "is the nightly job running?" escalations into a self-serve lookup for support and ops. It is not a monitoring or alerting product, and it is not a platform bet: adoption is essentially zero (1 GitHub star, no dependents, single maintainer), so we should treat it as source code we take ownership of, not a vendor dependency. Recommendation: timebox a one-day evaluation against a forked copy; success criterion is measurable reduction in schedule-related engineering interrupts. If the criterion isn't met, we keep the fork as internal tooling or drop it — either way, cost of exit is near zero. For anything revenue-critical, the real investment is a heartbeat/alerting service, which this does not replace.
To engineering: Thin Nova card over the framework's own scheduler introspection — low complexity, MIT-licensed, but effectively unmaintained and untested against current Nova majors. Plan to vendor/fork it, pin the version, and add it to the Nova-upgrade checklist. Do not let it become the thing we point to when someone asks "do we have job monitoring?" — that answer must remain an alerting tool with history and missed-run detection. If we like the UX, replicating it in-house is a few hours of work and removes the dependency entirely.