Cron Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for scheduling infrastructure. The core decision this package informs is whether to define scheduled work declaratively (in code/config) versus managing raw system crontab entries by hand. That is a real, recurring decision — but it is an infrastructure decision, not a product-feature decision, so it should be scoped to an ops/architecture spike rather than a roadmap line item.
• Consolidating schedules across a polyglot PHP estate. If we run legacy Symfony services alongside newer Laravel apps, a single way to express "run this console command on this interval" has genuine value: fewer snowflake crontabs, fewer 3am pages caused by a typo in /etc/cron.d, and schedules that travel with the code through review and deploy.
• Standardizing on-ramp for internal tooling. For low-stakes internal jobs (nightly exports, cache warmers, report generation), the decision is usually "is there a cheap, boring mechanism already in the stack?" This package is a candidate for that slot only in Symfony contexts.
• Not a lever for customer-facing roadmap work. Nothing here moves activation, retention, or revenue. Treat it as platform hygiene; do not let it consume roadmap capacity beyond a timeboxed evaluation.
• Flag for the record: despite being evaluated as a "Laravel/PHP package," this is a Symfony bundle. Laravel ships a first-class scheduler (Schedule facade + a single schedule:run cron entry) and Symfony has had an official symfony/scheduler component since 6.3. Either way, this package is duplicating something the framework already provides.

When to Consider This Package

Consider it only if all of the following hold:

• The target application is genuinely Symfony-based, not Laravel — for a Laravel app, this is a non-starter; use schedule:run and withoutOverlapping() / onOneServer() instead.
• You are on a Symfony version older than 6.3, so the native Scheduler component isn't available to you.
• The need is narrow and internal: periodic invocation of existing console commands, no sub-minute granularity, no distributed coordination, no per-job retry semantics.
• You are prepared to vendor the code or fork it into our own namespace — i.e., you are adopting it as source, not as a dependency you expect upstream to maintain.

Look elsewhere if any of the following apply — and on the available evidence, several do:

• Adoption signal is effectively zero. No stars, no dependents, hosted on a non-GitHub Gitea instance, no visible release history or version constraints in the metadata provided. That means no external bug-finding, no security response process we can rely on, and no community answer to "why did my job silently stop running?"
• No evidence of active maintenance or a stated support window. A scheduler that fails silently is worse than a crontab that fails loudly; unexplained gaps in a dependency that owns time-triggered execution are a reliability risk we cannot underwrite.
• Modern PHP frameworks already solve this. Symfony ≥6.3 (symfony/scheduler) and Laravel's built-in scheduler both cover the use case natively, with better tooling around overlap protection and monitoring.
• You need real scheduling primitives: distributed locks / single-runner guarantees, retries with backoff, jitter, timezones, observability hooks, or queue-backed dispatch. Reach for the framework scheduler plus a hosted cron monitor (Sentry Crons, Cronitor, Healthchecks) instead of a bare bundle.
• Supply-chain policy applies. Depending on an unmaintained package from an unfamiliar host to run code on a timer is an unnecessary attack surface; if adopted, it must be vendored and reviewed.

How to Pitch It (Stakeholders)

Recommendation: do not adopt as a dependency. Treat it as a reference pattern at most, and only in a pre-6.3 Symfony context.

For executives: This is a small utility that runs scheduled commands in Symfony apps — functionality both major PHP frameworks already ship. It has no adoption, no visible maintainer activity, and no support path, so making it load-bearing would add risk without adding capability. Cost of adopting: near-zero licence, non-trivial ongoing ownership. Cost of the alternative: one cron entry pointing at the framework's own scheduler. Decision: skip; the build-vs-buy answer here is "we already have it."

For engineering: The concrete comparison is fgits/cron-bundle vs. symfony/scheduler (6.3+) vs. Laravel's Schedule facade. The frameworks win on overlap protection, single-server execution, and ecosystem tooling. If we do have a pre-6.3 Symfony service with hand-maintained crontabs, the better play is a short internal spike: a thin config-driven runner over CommandTester, or a scheduled upgrade path to a version with the native component. Either is a few days of work and leaves us owning code we understand.

For the roadmap: No capacity requested beyond a half-day evaluation already completed. Revisit only if a concrete Symfony service surfaces with a scheduling need and no upgrade path — in which case the decision is "fork and own," not "depend."