Cron Laravel Package

Product Decisions This Supports

• Sub-minute scheduling feasibility. The core differentiator is seconds-resolution cron parsing, which opens product questions the standard 5-field cron format simply can't answer: near-real-time polling of partner APIs, SLA-sensitive retry windows, "check status every 15 seconds for two minutes" flows, and tighter queue-drain or webhook-reconciliation loops. This package lets you prototype and price those features without building a parser.
• Build vs. buy vs. vendor for scheduling primitives. Because it's a small, MIT-licensed derivative of the widely used dragonmantank/cron-expression parser, it shifts the decision from "do we write a cron parser?" to "do we vendor ~a few hundred lines and own them?" That's usually a much cheaper internal decision than a greenfield build.
• Scheduler vs. queue architecture. If a roadmap item needs intervals below one minute, you're deciding between (a) cron-driven scheduler ticks, (b) always-on workers with sleep loops, or (c) a queue with delayed jobs. Having a seconds-aware parser makes option (a) credible and lets you avoid standing up long-lived worker infrastructure for low-volume jobs.
• Customer-defined schedules. If tenants or admins configure their own schedules in a UI, you need a parser to validate and normalize input and to compute next-run times for display ("next run in 42 seconds"). This package gives you that surface, including the seconds field that end users often expect from a "schedule builder."
• Roadmap de-risking for "real-time-ish" features. Useful for a timeboxed spike to answer "is seconds-granularity good enough, or do we genuinely need an event bus/websocket layer?" Cheaper to answer with a parser than with infrastructure.
• Explicitly not a decision driver: framework integration. Despite the Laravel framing in the description, this is essentially a standalone PHP parser; it does not replace Laravel's scheduler, and Laravel already ships dragonmantank/cron-expression transitively. Adopting this does not modernize or extend the scheduler itself.

When to Consider This Package

Consider it when all of the following hold:

• You have a concrete, near-term requirement for seconds-level granularity in cron expressions — not a hypothetical one. Standard 5-field cron covers the overwhelming majority of product needs.
• The surface area you need is small and well understood: parse, validate, and compute next/previous run times. You are not expecting scheduling, dispatch, locking, timezone databases, or a daemon.
• You are comfortable vendoring the code into your repo (or pinning a fork) and treating it as first-party source you own. With 6 stars, 0 dependents, and a last release in November 2023, this is not a dependency you should expect upstream to maintain on your behalf.
• You accept a short evaluation spike — an afternoon or two — to verify behavior against your own edge cases: DST transitions, month-end rollovers, leap seconds/day handling, ranges and step values in the seconds field, and error messages for invalid input.
• You're targeting PHP/Laravel and want the parsing logic to sit alongside existing scheduled jobs without adding a new runtime or service.

Look elsewhere when:

• You need ordinary minute-granularity scheduling. Use dragonmantank/cron-expression directly — it's the mature upstream, it's already in your dependency tree via Laravel, and it carries the community, tests, and CVE attention this package does not.
• You need active maintenance, a published support policy, or a vendor to escalate to. Single-maintainer, low-adoption, stale releases are a poor fit for anything on a critical path.
• You need a full scheduling runtime (locks, overlapping-run prevention, misfire handling, distributed coordination). That's a queue/worker or a managed scheduler conversation, not a parser.
• Your compliance or supply-chain posture requires provenance review, signed releases, or a dependency with measurable adoption. Six stars and zero dependents will not clear that bar.
• Timezone/DST correctness is business-critical and you cannot invest in your own test suite around it. Assume you must validate this yourself rather than inherit it.
• You need expression authoring UX — human-readable descriptions, builder helpers, i18n. Not in scope here.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a small class of roadmap features — frequent polling, fast retries, near-real-time status checks — that standard one-minute cron can't express. There's a small open-source MIT-licensed parser that handles seconds-level schedules and is based on a well-established library we already depend on indirectly. The cost to evaluate is a couple of engineering days; the cost to adopt is low because it's a few hundred lines of source we can own outright. The risk is maintenance, not licensing: it has essentially no user base and hasn't shipped since late 2023. Recommendation: fund a timeboxed spike to prove the seconds-granularity path, and if it works, vendor the code and treat it as first-party rather than as an external dependency we rely on someone else to keep alive.

To engineering: Treat this as reference source, not a dependency. It's a thin derivative of dragonmantank/cron-expression with seconds-field support; that's the whole value proposition. Before adopting, confirm the seconds semantics you need, write tests for DST and boundary cases, decide whether to fork or vendor, and confirm you're not accidentally introducing a second cron-parsing implementation alongside Laravel's built-in one — a duplicate-parser code path is a real long-term cost for a marginal feature. If the requirement turns out to be minute-level after all, drop this and use the upstream library.