Project Template Bundle Laravel Package

Product Decisions This Supports

• Observability roadmap: "did the cron actually run?" Release 0.8.16 makes cron executions visible live in queue_job_logs and introduces a queued status, so a scheduled job's lifecycle (queued → running → finished/failed) is queryable from your own database. This directly supports decisions about whether to build an internal ops dashboard versus buying a scheduler-monitoring SaaS.
• Build vs. buy for job monitoring. If your only real need is "know whether scheduled/queued work ran and how long it took," this release makes the in-house path credible. It argues against adding a dedicated cron-monitoring vendor for small-to-mid projects.
• Support-cost reduction. A per-run runId on RunCronMessage gives a correlation key across dispatch, execution, and log rows. That turns recurring "the nightly job didn't run" support tickets into a single indexed lookup — a measurable reduction in on-call and support effort.
• Feature scoping for alerting. Because status is persisted rather than ephemeral, failure/staleness alerting becomes a thin layer on top of existing data rather than a new subsystem. This is a good candidate to slot into a near-term roadmap item rather than a standalone project.
• Prioritisation signal for the queue/scheduling epic. Additive, low-risk changes like this are cheap to adopt now and de-risk later work (retention policies, SLA reporting, run history UI) that would otherwise need to be designed from scratch.

When to Consider This Package

Adopt when:

• Your scheduled and background work already flows through Laravel's queue and you want run history without standing up separate infrastructure.
• You need a cheap correlation ID (runId) to tie a cron trigger to the jobs and logs it produced.
• You are comfortable consuming a 0.x package — pin the version explicitly and expect schema/migration churn in queue_job_logs.
• Your volume is modest enough that writing job status rows into your primary database is acceptable.

Look elsewhere when:

• You need distributed tracing, log retention at high volume, or cross-service correlation — reach for OpenTelemetry, a hosted observability platform, or Laravel Horizon/Telescope if already in place.
• You require a stable public API and upgrade guarantees; wait for a 1.0 or vendor the relevant piece.
• You have customised or subclassed RunCronMessage. The added runId changes the message payload shape — audit consumers and serialized messages in flight before deploying.
• Your queue throughput makes per-job database writes a contention risk; prefer a dedicated monitoring store.

How to Pitch It (Stakeholders)

For executives: A small, additive upgrade that makes scheduled background work observable in our existing database. It answers "did the job run, when, and under which run?" without buying another monitoring tool — lowering both vendor spend and the support burden of silent cron failures.

For engineering: Version 0.8.16 adds live cron execution records to queue_job_logs, a new queued status, and a runId on RunCronMessage for correlation. The changes are additive but touch a persisted table and a message payload, so plan a migration and verify any custom RunCronMessage consumers or in-flight serialized messages. Pin the version — the package is still pre-1.0, so treat the log schema as unstable and isolate reads behind a small internal query layer so future changes stay contained.