Heroku Scheduler Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (outcome: build). This package is the prior art for a narrow pattern — a single console entrypoint that Heroku Scheduler pings on a fixed cadence, which then dispatches whatever internal tasks are actually due. That pattern is now ~20 lines of framework glue. The package itself is a reference design, not a dependency decision.
• Roadmap feasibility for recurring product behavior. Anything periodic — daily digests, trial-expiry emails, abandoned-cart sweeps, billing retries, sync jobs — inherits a hard constraint from Heroku Scheduler: fixed intervals (10 min / hourly / daily), no cron expressions, no sub-10-minute granularity. This package exists specifically because of that constraint, so it's a useful marker of the platform's ceiling when scoping SLAs ("how fresh can this data be?").
• Dependency health gate. Zero dependents, 1 star, last release March 2016, and it's a Symfony bundle, not Laravel. That combination should trip a standard "do not adopt" rule in any dependency review and is itself a useful calibration data point for our adoption checklist.
• Maintenance budget forecasting. If anyone proposes it, the real cost isn't integration — it's owning a fork: PHP 8 compatibility, Symfony major-version drift, and no upstream patch path. That's a recurring line item, not a one-time one.

When to Consider This Package

Effectively never for new work. The only defensible scenario is a legacy Symfony 2.x/3.x application already on Heroku Scheduler, pinned to PHP 5.x/7.0, where writing the glue yourself is genuinely blocked — and even then, only after a security review and with an explicit decision to fork and own it.

Look elsewhere when:

• You're on Laravel. Use the native scheduler (routes/console.php / Kernel::schedule()) and have Heroku Scheduler run php artisan schedule:run every 10 minutes. Richer, maintained, first-party, supports withoutOverlapping() and onOneServer().
• You're on modern Symfony. Use the framework's symfony/scheduler component (6.3+) or a maintained cron bundle.
• You need sub-10-minute granularity, retries, or execution guarantees. Heroku Scheduler cannot provide them. Move to a worker dyno running schedule:work, a cron add-on, or a proper queue with delayed jobs.
• You're not on Heroku. Plain cron, systemd timers, or Kubernetes CronJobs solve this without a third-party package.

How to Pitch It (Stakeholders)

To executives: Recommend against adoption. This is a 2016 Symfony bundle with one star and zero dependents — effectively abandoned — and it doesn't even target our stack. Adopting it buys us nothing that the framework doesn't already ship, while adding an unmaintained dependency we'd have to fork and patch ourselves. The decision is "build vs. configure," not "buy": roughly half a day of engineering, no vendor contract, no procurement cycle.

To engineering: We're not taking the dependency. For Laravel, the replacement is php artisan schedule:run invoked every 10 minutes by Heroku Scheduler, with scheduled logic living in our own repo and guarded by withoutOverlapping() and onOneServer(). Flag the platform constraint upward: Heroku Scheduler's fixed intervals and lack of retry semantics cap how reliable our periodic jobs can be. If a roadmap item needs tighter cadence or delivery guarantees, that's a separate budget ask for a dedicated scheduler process or a cron add-on — surface it early rather than discovering it mid-build.