Statamic Scheduled Cache Invalidator Laravel Package

Product Decisions This Supports

• Cache freshness strategy for Statamic sites. This addon lets you schedule cache invalidation (rather than relying on TTL expiry or manual "clear cache" clicks), so it directly informs a decision about how content freshness is guaranteed on a content-heavy site. That's a product-visible reliability question, not just an infra detail.
• Build vs. buy (or build vs. install). The alternative is a bespoke Laravel scheduled command/job that calls cache-forget APIs on a cron. This package is the "buy" option; the 2.2.1 patch (an Eloquent model update) is evidence the "buy" option is still actively maintained and tracking current Laravel conventions rather than rotting.
• Roadmap input for time-sensitive publishing. If the roadmap includes scheduled campaigns, embargoed content, timed promotions, or coordinated multi-site rollouts, scheduled invalidation is a prerequisite capability. This release is a low-risk enabler to slot into a maintenance sprint rather than a feature sprint.
• Use cases worth naming in a PRD: a marketing site with campaign pages that must go live/come down at a known time; statically cached pages or a CDN layer that needs a predictable purge window; editorial teams who publish on a schedule and shouldn't have to remember to flush cache.

When to Consider This Package

Consider it when:

• You run Statamic and have a caching layer in front of it (static caching, response cache, or CDN) where staleness is a timing problem, not a correctness problem.
• Your invalidation times are predictable — campaign launches, publish windows, nightly rebuilds. Predictability is what makes scheduling the right primitive.
• Your team already operates the Laravel scheduler and cron; this adds configuration, not new operational machinery.
• You want invalidation behavior owned by configuration/content editors rather than encoded in application code.

Look elsewhere when:

• You need event-driven invalidation on save/publish. Statamic's own cache/static-caching behavior and Laravel's cache events are the better fit; layering a scheduler on top adds a second, competing source of truth.
• You need sub-minute freshness or per-user personalization — prefer short TTLs or edge logic instead of scheduled purges.
• You're not on Statamic, or you're on a Statamic version outside the package's supported range.
• Single-maintainer dependency risk is unacceptable for your org. This is a small, narrowly-scoped addon from one maintainer; if it's business-critical, plan to vendor/fork it or wrap it behind your own interface so it can be swapped.

On 2.2.1 specifically: it's a patch release containing an Eloquent-related update. Treat it as a routine upgrade, not a decision point — no new capability to evaluate and no advertised breaking change. Before adopting, confirm the package's Laravel/Statamic version constraints still match your stack and run your test suite; "Eloquent update" can mean adopting newer model conventions, which occasionally surfaces on older framework versions.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small, free Statamic add-on that lets us schedule when cached pages get refreshed, instead of relying on engineers to clear cache manually or on arbitrary expiry timers. The business value is reduced risk of stale or wrong content during time-sensitive moments — campaign launches, promotions, scheduled announcements — without adding engineering headcount to every publish. The dependency is narrow and the project is actively maintained (a patch release just landed), so integration cost and risk are both low. The main caveat is that it's a single-maintainer open-source package, so if we make it load-bearing we should treat it as a dependency to monitor, not a set-and-forget.

For engineering (the short version): Adds configuration-driven scheduled cache invalidation on top of the Laravel scheduler, replacing hand-rolled artisan commands. 2.2.1 is a patch with an Eloquent model update — no new features, no advertised breaking changes; verify version constraints against our Laravel/Statamic versions and run the suite. Recommend wrapping it behind a thin internal interface so a future swap or fork is a contained change.