Command Scheduler Laravel Package

Product Decisions This Supports

• Reliability/observability roadmap: The package centers on ScheduledCommandHistory — i.e., a durable record of what scheduled commands ran, when, and with what outcome. That supports decisions about on-call coverage, SLA/uptime commitments, and whether to invest in a proper scheduler-observability layer versus ad-hoc logging.
• Build vs. buy: Attribute-driven command history is a small, well-scoped capability. Buying it (composer dependency) is almost always cheaper than a bespoke audit table + listeners, freeing engineering time for differentiated work.
• Audit/compliance use cases: Run history is directly reusable for regulated or enterprise customers who ask "prove this nightly job executed." Useful in sales conversations for security/compliance-sensitive segments.
• Developer-experience roadmap: The move to attribute-based configuration (ScheduledCommandHistory via attributes) lowers boilerplate. That's a signal the package is tracking modern PHP/Laravel idioms, which matters when planning a PHP 8+ / Laravel upgrade path.
• Release-risk triage: v5.0.6 is a maintenance-only patch — coding standards, PHPStan fixes in tests, and a test-infrastructure fix for Doctrine service injection. No breaking changes, no deprecations, no new user-facing features, so no migration or roadmap impact. It's safe to absorb in a routine dependency bump.
• Maintainer-health signal: Repeated PHPStan and coding-standard work indicates an actively maintained, quality-gated project — a positive input when deciding whether to standardize on it across multiple services.

When to Consider This Package

Adopt when:

• You run a non-trivial number of Laravel scheduled tasks and lack a queryable history of their execution.
• You want audit/run-log evidence for support, compliance, or customer reporting without building it yourself.
• Your codebase is on PHP 8+ and comfortable with attribute-based configuration.
• You already run (or are willing to run) Doctrine components — the release notes confirm a Doctrine service is part of the test/runtime wiring, so this is not a zero-dependency package.
• You want a low-risk, incremental add: patch-level releases like v5.0.6 mean low upgrade tax.

Look elsewhere when:

• You need full APM, alerting, or failure paging — pair with (or prefer) Horizon, Telescope, Sentry, or a hosted monitor rather than treating this as a monitoring substitute.
• You need queue/job-level throughput metrics, distributed tracing, or dashboarding out of the box.
• Doctrine is a hard no in your stack; forcing in Doctrine DBAL purely for run history is disproportionate.
• You require a large vendor-backed SLA — this reads as a focused, maintainer-led package; confirm bus-factor and release cadence before making it load-bearing.
• The unresolved "Doctrine service injection in tests" item matters to you — it's test-harness fragility, not a production defect, but worth watching if you plan to contribute or fork.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost add-on that gives us a reliable record of whether our scheduled background jobs actually ran. It supports uptime commitments, answers customer and auditor questions about job execution, and costs us a dependency bump rather than a build project. The latest release (v5.0.6) is a maintenance patch — no disruption, no migration, which tells us the project is being actively looked after.

To engineering: Adopt for scheduled-command history, configured via attributes rather than boilerplate. It brings Doctrine along as a dependency, so validate that fits our stack before committing. v5.0.6 is hygiene-only — coding standards, PHPStan fixes in tests, and a test-side Doctrine injection fix — so expect a clean upgrade. It is not a replacement for Horizon/Telescope/Sentry; treat it as the audit layer beneath those, and keep alerting in the tool that already owns it.