Console Command Scheduler Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for scheduled task management. If your product runs Symfony 6.3+ and already depends on Messenger and EasyAdmin, this bundle replaces a bespoke "cron-job admin" with a ready CRUD + logging + trigger layer. That saves an estimated 3–6 weeks of engineering for a feature that rarely differentiates your product.
• Roadmap: internal-ops and back-office tooling. The bundle's value is entirely in operator experience — a UI to add/edit/toggle scheduled console commands, per-task log files, DB-backed execution history (last run, duration, return code), and email-based notification hooks. It is an enabler for an "ops console" roadmap item, not a customer-facing feature.
• Feature scoping: ETL and batch workloads. Originally built for an ETL project, it fits products with recurring ingestion, exports, syncs, or report generation where business users need to adjust schedules without a deploy.
• Use-case prioritization: reliability features. The 2.1+ additions (input validation on frequency/cron, fault isolation with SchedulerEntryFaultedEvent, a bytespin:scheduler:lint CI command, and missed-run semantics) directly support a "scheduling is safe to trust unattended" OKR and are the strongest reason to adopt over hand-rolling.
• Buy vs. build for observability. Execution logs and red "invalid" badges in the admin list reduce the need for a separate scheduling-observability tool in early-stage products.
• Workflow segmentation. The optional tags feature supports organizing tasks by team, environment, or business unit — useful if the roadmap includes multi-tenant or multi-team ops governance.
• Queue isolation decisions. Per-task Messenger queue selection lets you route long-running jobs away from the default scheduler queue — a product decision about performance isolation you can now make per task rather than architecturally.

When to Consider This Package

Consider adoption when all of the following hold:

• You are on Symfony 6.3+ / PHP 8.2+ and are comfortable with the Scheduler component's evolving status. (Note: this is not a Laravel package; Laravel teams should stop here and evaluate Laravel's native scheduler.)
• You already use, or are willing to adopt, EasyAdmin, Doctrine, and Messenger with a running messenger:consume worker.
• You need operators — not developers — to create and modify recurring console commands through a UI.
• You want DB and file logging of executions out of the box and are willing to run doctrine:schema:update --force (and repeat it on upgrades, since no Doctrine recipe exists).
• You have or can write listeners on the before/success/failure/fault events to plug into your alerting stack.
• You can wire bytespin:scheduler:lint into CI or your deploy pipeline.

Look elsewhere or build in-house when:

• Maturity is a hard requirement. The project self-describes as beta, has 0 stars and 0 dependents, and ships no Doctrine migrations recipe — schema changes are manual and version-coupled (last schema-modifying release is 1.1.0). For a revenue-critical scheduler, that's a meaningful operational tax.
• You don't want EasyAdmin. The admin UI is not optional in spirit; you provide your own DashboardController and menu wiring.
• Multi-entity-manager setups. auto_mapping: true breaks the bundle's getManagerForClass() resolution; you must hand-map every entity. Non-trivial for large legacy apps.
• Laravel, or non-Symfony PHP. No fit.
• You need horizontal-scale scheduler semantics, dependency graphs between jobs, or SLA-grade guarantees — this is a single-worker Messenger pattern, not an orchestration platform.
• Vendor risk tolerance is low. One maintainer, zero community validation, no funding signal. Budget for the possibility you fork it.

How to Pitch It (Stakeholders)

For executives (30 seconds): We can add a self-service scheduling console to our Symfony app in days instead of weeks. Operators get a UI to schedule and toggle recurring commands, with execution history, logs, and email alerts; engineering gets validated inputs and a CI check that prevents a bad schedule from taking the scheduler down. It's MIT-licensed and free, but it's a beta project with a single maintainer and no adoption yet — so we adopt it deliberately, keep our event-listener integration thin, and treat forking as a realistic contingency.

For engineering leads: This is a thin bundle over Symfony's Scheduler component that persists schedules as Doctrine entities and exposes EasyAdmin CRUD. The integration surface is small and mostly declarative: register the bundle, map its entities to an entity manager (careful — disable auto_mapping), run the configuration command, and schedule a messenger:consume scheduler_scheduler worker under Supervisor. The 2.1+ reliability work is the selling point: class-level validation catches the classic "cron expression in the interval field" mistake at form-submit time, SchedulerEntryFaultedEvent plus fault isolation means one bad entry is skipped and logged rather than crashing the worker, and bytespin:scheduler:lint exits non-zero so we can gate deploys. Missed runs default to at-most-one catch-up per task — sensible, and configurable if we disagree. Our real work is the event listeners (before/success/failure/faulted) to route into our existing alerting, and a policy for schema updates on version bumps.

For the product team: This converts "ask an engineer to add a cron job" into a form. It's scoped to internal operations — the value is engineer-hours saved and fewer 2 a.m. pages, not new customer features. Success looks like: reduced scheduling-related incidents, most recurring tasks self-served by ops, and zero scheduler-wide outages traced to a single misconfigured entry.

Risks to state plainly: beta status; no maintainer bench; manual schema updates on upgrade; EasyAdmin coupling; and zero ecosystem validation (0 stars/dependents), which means no safety net of other users finding bugs first. Mitigation: pin the version, wrap our listeners in our own interfaces, and reserve a spike to fork if the project stalls.