Laravel Scheduled Notifications Laravel Package

Product Decisions This Supports

• Feature: lifecycle and reminder messaging without a new vendor. Snooze lets a Laravel model schedule a future notification (e.g. "trial ends in 3 days," "invoice overdue," "onboarding step 2 unsent") and cancel or reschedule it when the underlying record changes. This supports decisions like do we ship automated follow-ups this quarter? without procuring a marketing automation platform.
• Build vs buy. For teams already on Laravel + Queues, this is the "buy the small piece" option: the alternative is hand-rolling a scheduled_notifications table, a polymorphic relation, cancellation logic, and queue dispatch — roughly 1–3 weeks of engineering plus ongoing edge-case maintenance. Snooze collapses that to a composer require and a trait.
• Roadmap sequencing. Because scheduling is a primitive, once adopted it unlocks a family of related features cheaply: re-engagement nudges, digest emails, in-app "snooze this task" UX, SLA/escalation reminders, and dunning sequences. It is an enabler, not a standalone feature, so it belongs early in a lifecycle-messaging roadmap.
• Scope guardrail. It schedules notifications, not campaigns. Decisions about segmentation, A/B testing, visual journey builders, and cross-channel orchestration remain out of scope and should be routed to a marketing platform — this keeps the build small.
• Upgrade and platform decisions. The 2.9.1 release adds Laravel 13 support with no breaking changes, which is the signal a PM needs for the framework-upgrade decision: this dependency will not block a Laravel 13 migration, and the maintainer is tracking upstream releases. Confirm the Laravel 13 constraint in composer.json before committing the upgrade plan.

When to Consider This Package

Adopt when:

• The product is a Laravel application already running database-backed queues; Snooze rides existing infrastructure rather than adding a service.
• Reminders are record-scoped and mutable — the classic pattern is "schedule X for this Order/User/Subscription, and cancel it if the record's state changes." That is precisely the problem this package solves and the one most homegrown implementations get wrong (orphaned sends after a refund, cancellation, or status flip).
• The team is small and would rather not own a scheduling subsystem, its tests, and its cron/queue failure modes.
• Volume is moderate and notifications are transactional or near-transactional rather than high-volume marketing blasts.
• You want the "snooze" interaction itself (defer a task/reminder to later) as a user-facing pattern.

Look elsewhere when:

• You need campaign authoring, segmentation, drip builders, or multi-channel orchestration — that is Customer.io / Braze / Klaviyo territory, and forcing it here creates a maintenance trap.
• Deliverability, send-time optimization, or per-user timezone intelligence at scale are requirements; those need dedicated tooling.
• The application is not Laravel, or the team standardizes on event buses outside the framework's queue system.
• You need guaranteed exactly-once semantics with audit-grade delivery reporting; queue-backed scheduling gives at-least-once behavior and requires idempotent notification classes.
• Dependency-risk posture is strict. This is a single-maintainer package. It is well-established with meaningful adoption, but a PM should note bus-factor risk and require a documented fallback (the data lives in your own database table, so extraction is feasible) before making it load-bearing for revenue-critical messaging.

How to Pitch It (Stakeholders)

To executives: This is a small, mature Laravel package that lets us ship scheduled and cancellable customer reminders — trial-expiry nudges, payment follow-ups, onboarding steps — in days instead of building and maintaining that machinery ourselves. It runs on infrastructure we already pay for (our database and queue workers), so there is no new vendor contract, no new data processor to review, and no additional per-message cost. The latest release (2.9.1) is a maintenance update that adds Laravel 13 compatibility with no breaking changes, which means adopting it does not create a future framework-upgrade blocker — a common hidden cost with smaller packages. Principal risk is that it is maintained by a single author; we mitigate that because all scheduled state lives in our own database, so we can fork or replace it without data loss. Recommendation: adopt for lifecycle reminders, keep campaign-level marketing in a dedicated platform.

To engineering: Dependency thomasjohnkane/snooze 2.9.1. Adds a snoozes polymorphic table plus a ShouldSnooze trait on models; scheduling is queue-driven, so behavior inherits our existing queue guarantees (at-least-once — notification classes should be idempotent). Cancellation and rescheduling are first-class, which is the part we would otherwise write and get wrong. 2.9.1 widens support to Laravel 13; verify the constraint and run the upgrade path in CI. Surface area is small enough to read in an afternoon and to fork if needed.