Cron Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for scheduling administration. If the roadmap includes letting internal ops staff or customers view, edit, pause, or manually trigger scheduled jobs without a deploy, this package replaces a bespoke admin CRUD screen (typically 1–3 sprints of engineering plus ongoing maintenance). That is the core buy decision it informs.
• Multi-tenant / self-serve scheduling. For B2B SaaS where each tenant needs its own recurring jobs (reports, syncs, digests, billing retries), a DB-backed cron manager turns "engineering ticket to add a schedule" into a product feature. This is usually a roadmap item, not an infrastructure detail — the package determines whether it is cheap or expensive.
• Observability and on-call scope. A cron manager's value is often less about editing schedules and more about run history, exit codes, duration, and failure visibility. That directly supports decisions about alerting investment, SLA commitments, and whether ops needs a dashboard before headcount is added.
• Deployment/architecture choices. A package that stores schedules in the database rather than in app/Console/Kernel.php implies a migration, a seeder/backfill strategy, and a UI. That is a real architectural commitment; the decision should be made explicitly, not inherited from a single developer's preference.
• Support cost modelling. Customer-configurable schedules increase the surface area of "my report didn't run" tickets. Weigh the package against the support hours it absorbs (self-service + logs) versus the hours it creates (misconfiguration, overlapping runs, timezone confusion).
• Scope boundary: choose this for scheduling management and visibility on a Laravel monolith. Do not use it to justify building a general workflow/orchestration platform — that is a different (and much larger) decision.

When to Consider This Package

Consider it when:

• The product is Laravel/PHP and schedules currently live in code, and non-engineers (ops, support, account managers, or tenants) need to change them.
• There are enough schedules (roughly more than a handful, or growing per-tenant) that code-reviewed schedule definitions have become a bottleneck or a recurring ticket category.
• You need run history, last-run status, and failure visibility that Laravel's native scheduler does not persist, and you do not already have APM/cron monitoring (Sentry Crons, Healthchecks.io, Oh Dear) covering it.
• Manual "run now" and pause/resume are genuine product or support requirements.
• The team is small enough that owning a custom admin UI is a poor use of capacity.

Look elsewhere / stay native when:

• Fewer than ~10 static schedules and engineering controls them comfortably — Laravel's built-in scheduler plus a monitoring service is cheaper and has no dependency risk.
• You need distributed execution, retries with backoff, DAGs, or high fan-out — that is Temporal, Airflow, Cloud Scheduler, or a queue-based design, not a cron manager.
• You cannot accept the operational risk of letting users define commands. Most cron managers execute configured commands or job classes; if the input surface is not tightly constrained to an allowlist, this becomes a privilege-escalation problem. Treat this as a hard gate, not a nice-to-have.
• Compliance or platform policy restricts third-party packages, or the vendor shows single-maintainer risk with no recent activity. Verify before adopting: current release cadence, PHP/Laravel version support matrix, test coverage, open issue count, security policy, license, and whether v7 dropped support for your Laravel version.
• Caveat on this specific release: the 7.0.1 notes contain only a changelog link with no described changes, which is consistent with a patch-level bugfix. Do not read it as a feature or stability endorsement. Confirm the actual diff and, because it is a major version line, confirm the Laravel/PHP compatibility matrix and any upgrade steps before committing a roadmap item to it.

How to Pitch It (Stakeholders)

For executives (30 seconds): We currently hard-code every recurring job, so each schedule change is a ticket, a code review, and a deploy. This package gives us a database-driven control panel for those jobs — who can change them, when they last ran, and whether they failed — for a fraction of the cost of building it ourselves. It is the difference between scheduling being an engineering chore and scheduling being a feature we can hand to ops or to customers. The decision to approve is a build-vs-buy one; the risk to manage is dependency and security review, not capability.

For engineering: This is a thin management layer over Laravel's own scheduler — it does not replace the queue, the scheduler daemon, or your monitoring. Adopting it means a migration, a seeded backfill of existing schedules, and a policy for which commands are runnable (allowlist only). Validate the v7 compatibility matrix and read the 7.0.1 diff, since the release notes are empty. Confirm behaviour for overlapping runs, timezones, and failed-job retries, and require that run history is queryable so we can hook it into existing alerting rather than building a second paging path.

For product/ops: The win is self-service and traceability — fewer "did the nightly import run?" threads, and a defensible audit trail when someone asks who changed a schedule. The trade-off is that misconfiguration becomes possible without a deploy, so we should ship it with sane defaults, pause-before-delete, and visible last-run status rather than an empty form.