Cron Laravel Package

Product Decisions This Supports

• Standardizing scheduled work as code instead of crontab sprawl. The core value is that a recurring job becomes a tagged Symfony service with a schedule and category declared in the repo, rather than a line someone SSH'd into a server to add. That supports the decision to make scheduling reviewable, diffable, and deployable — a governance win more than a technical one.
• Choosing "one scheduler entry point" over "N bespoke cron entries" per environment. The README's recommended pattern (* * * * * ibexa:cron:run) collapses dozens of system cron lines into a single OS-level entry. This is a real operational simplification for ops runbooks, container images, and environment parity (dev/staging/prod behaving identically).
• Tiering jobs by criticality via category. Categories let you split high-frequency, business-critical jobs from infrequent housekeeping, and run them under different system cron cadences or supervision. Useful when deciding which jobs deserve alerting and which can fail silently.
• Roadmap input for cluster/multi-node execution. The maintainers explicitly signal the intended direction: separating jobs that must run on all nodes versus exactly one node, plus a locking layer. If your roadmap includes horizontal scaling or HA, this tells you the capability is anticipated but not shipped — so it is a "plan around it," not a "plan on it" decision.
• A build-vs-buy fork with a cheap third option. Rather than building an in-house scheduler or buying an enterprise one, this is the "assemble from small, replaceable parts" path: cron/cron for parsing, a thin command for execution, Symfony's service container for registration. The decision it supports is deliberately deferring the scheduler investment.
• Build-vs-adopt benchmark for Laravel/PHP teams. For a Laravel shop this is not a candidate dependency — Laravel already ships Illuminate\Console\Scheduling and a schedule:run entry point with overlapping (and more mature) semantics. Read this package as a design reference for how to expose scheduling, not as a library to install. That distinction is itself a product decision worth documenting.

When to Consider This Package

Consider it when all of the following hold:

• You are already running Ibexa DXP or a Symfony console application — the package is a thin adapter over cron/cron, and it earns its place only by saving you ~50 lines of glue you'd otherwise write yourself.
• Your scheduled jobs are modest in number (tens, not hundreds) and single-node or tolerant of duplicate execution.
• You want schedules versioned alongside the commands they trigger, and your team is comfortable with service tags in YAML/PHP config.
• You are content that a missed job is recoverable — this is a fire-and-forget cron trigger, with no built-in retry, backoff, dead-letter, or execution history.
• You accept a vendor-owned, low-adoption dependency and have budgeted a fallback (it is small enough to fork or reimplement in an afternoon).

Look elsewhere when:

• Cluster/HA correctness is a requirement today. The one-node-only guarantee and lock system are described as future intent. Running this across replicas without external locking risks duplicate side effects — duplicate invoices, duplicate emails, duplicate sync operations. Use a queue-based scheduler with a distributed lock, or cron/cron-bundle, or your platform's native primitives (Kubernetes CronJob with concurrencyPolicy: Forbid, systemd timers, cloud schedulers).
• You need observability. No dashboard, no run history, no failure alerting, no SLA metrics. If "did the nightly job run and did it succeed?" is a question anyone asks, pair this with real instrumentation or pick something else.
• You need long-running or resource-heavy jobs. Cron-triggered process spawning is a poor fit; that's a queue/worker problem (Symfony Messenger, Laravel Queues, Sidekiq-equivalents).
• You want dependency-based workflows (job B only after job A succeeds). Cron expressions express time, not causality.
• License hygiene blocks you. The NOASSERTION classification is a compliance flag, not a formality — legal review is a prerequisite before shipping this in a distributed product. Do not let it into a customer-facing build on the assumption it's "probably MIT."
• You are a Laravel shop. Use the framework's scheduler. Adopting a Symfony-tagged-service scheduler into Laravel means fighting both ecosystems for zero benefit.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a small, low-cost piece of plumbing that lets our engineering team declare scheduled jobs in code instead of hand-editing server crontabs. The upside is operational: fewer places for drift to hide, schedules that get code review, and one cron entry per environment instead of dozens. The caveats are equally clear — it is an immature, vendor-published package with negligible community adoption, an unresolved license classification, and no built-in protection against the same job running twice when we scale to multiple servers. Recommendation: approve as an internal convenience inside our existing Ibexa/Symfony estate, capped at non-critical jobs, with legal sign-off on the license and no dependency on it for anything revenue-affecting. It is a tactical simplifying move, not a strategic platform bet.

To engineering — the short version: It's cron/cron plus a console command and a service tag. You tag a command with ibexa.cron.job, give it a crontab expression and a category, point system cron at ibexa:cron:run, and you're done. It buys you schedule-as-code and category-based tiering. It does not buy you locking, retries, history, or multi-node semantics — the README is explicit that cluster support and a lock system are planned, not present. If we're running more than one app node, we either add our own lock (e.g. a database or cache-based mutex wrapper) or we don't use this. It's ~a few hundred lines of surface area, so the exit cost is near zero, which is exactly why it's a reasonable experiment.

To the platform/ops team: The win is that your crontab shrinks to one line per category. The ask is that you own the supervision layer around it — process exit codes, alerting on missing runs, and a decision on what happens when a run overlaps the previous one. This package deliberately doesn't solve that, so it lands with you.