Scheduling Laravel Package

Product Decisions This Supports

• Ops visibility as a product surface. This package turns Laravel's schedule() definitions in app/Console/Kernel.php into a browsable admin page — task list, cron expression, last run, next run, and captured output. For a PM, that's the difference between "the nightly sync silently stopped three weeks ago" being discovered by a customer versus by an operator. It converts a developer-only concern into a supportable, auditable feature.
• Build vs. buy on internal tooling. The alternative is building an internal cron dashboard (or paying for a hosted scheduler/monitoring SaaS). At 92 stars and a 2021 last release, "buy" here really means "adopt and vendor an MIT-licensed extension," so the honest comparison is ~2–5 days of engineering to replicate the UI versus near-zero integration cost plus ongoing maintenance ownership.
• Roadmap input for admin/back-office features. If the product already ships laravel-admin as the operational console, this reveals a recurring user need: non-engineers want to see and trigger background jobs without SSH and php artisan schedule:run. That need usually generalizes into a "job health" panel, which is roadmap-relevant regardless of whether this specific package is adopted.
• Support and incident-response scope. A read-only view of scheduled task status and recent output materially shortens triage. That's a support-cost decision (fewer escalations to engineering), not a pure feature decision.
• Use cases that fit: single-tenant or small-fleet Laravel apps, internal tools, admin-heavy back offices, China-market deployments already standardized on laravel-admin, and teams where the on-call rotation is thin and humans need a "run it now" button.
• What it does not decide: it is a control panel, not a scheduler or a monitor. It won't give you alerting, distributed locking across multiple app servers, retry/backoff policy, or historical trend data. Don't let adoption of this package close the door on a real observability decision (Sentry Crons, Healthchecks.io, Horizon for queues) — those are complementary line items, not substitutes.

When to Consider This Package

Adopt when all of these hold:

• laravel-admin is already a first-class part of your stack. This extension is inert without it — it's a page in that panel, not a standalone tool.
• Your scheduling lives in the classic app/Console/Kernel.php style that the package introspects, and you're on a Laravel version it still supports (released Oct 2021, so realistically Laravel 8-era; verify before assuming 10/11 compatibility).
• You're on a single app server, or you accept that "run now" against one node is good enough.
• You can fork it. MIT license and an inactive upstream mean you must be willing to own the code: pin the version, vendor it, and assign a named maintainer.

Look elsewhere when:

• You aren't on laravel-admin. Use spatie/laravel-schedule-monitor (purpose-built for monitoring and alerting), Laravel Horizon if the real pain is queues, or a hosted cron monitor if the requirement is paging a human at 3am.
• You need multi-node correctness: distributed locks, overlap prevention, per-environment targeting. This package doesn't solve that, and pretending it does is how you get duplicate invoices.
• The requirement is alerting. A dashboard nobody opens is not monitoring. If the actual user story is "tell me when a task fails," buy a monitor; don't ship a page.
• Your security posture forbids admin-panel write access to production jobs. A "run now" button is effectively arbitrary command execution behind an auth boundary — get a security review before it ships.

Risk callout for the decision record: zero dependents, no release since October 2021, and a low opportunity score. Treat this as vendored example code you inherit, not a dependency you consume. Budget a maintenance line item and a deprecation path from day one.

How to Pitch It (Stakeholders)

To executives: Laravel applications run background jobs — nightly imports, invoice generation, cleanup — on a timer, and today nobody outside engineering can see whether those ran. This extension adds one screen to the admin panel we already operate, showing every scheduled task, when it last ran, whether it succeeded, and what it printed. It's MIT-licensed, so the cost is integration time, not license fees, and it directly reduces the class of incident where a customer discovers our failure before we do. Caveat stated plainly: the upstream project hasn't shipped since 2021, so we should treat it as code we adopt and maintain, and it is a visibility tool — not a replacement for real alerting, which remains a separate, small budget line.

To engineering: It's a thin laravel-admin extension that reads the schedule definitions from the console kernel and renders them as a grid with run/enable controls and captured output. Low integration cost if we're already on laravel-admin; zero value if we're not. Two asks before merge: confirm it runs on our Laravel version (last release predates 9/10), and decide explicitly whether a web-triggered "run now" is acceptable in production against our auth and audit requirements. Plan to fork and pin — nobody upstream is going to fix this for us.

To design/support: This gives the support team a first-line diagnostic they currently escalate to engineering: "did the 2am job run, and what did it say?" Expect requests to extend it into retry buttons and failure notifications — scope those into the monitoring discussion rather than bolting them onto this page.