Filament Ops Notify Laravel Package

Product Decisions This Supports

• Build vs buy for internal alerting. This package already covers dedupe, burst suppression, digesting, per-destination routing, a review panel, and Horizon visibility — the plumbing a team otherwise hand-rolls into a SlackNotifier class and regrets six months later. Adopting it removes an item from the backlog rather than adding one.
• Feature design: "alerting must never cost the user's request." v1.3.1 makes the failure-isolation contract explicit — OpsMessage::send() degrades to a log line when the cache is unreachable instead of 500-ing the request that triggered it. That is a product guarantee you can cite in design review when deciding whether a notification is inline, queued, or fire-and-forget.
• Roadmap: noise reduction vs. completeness. The burst guard + digest path lets you choose "one summary per window" over "one message per event" per destination, and the destination-scoped burst key means expanding from one chat to two topics (or two teams) is now a config decision, not a correctness bug.
• Use cases it fits: inquiry/lead saved, build finished, payment webhook failed, nightly job crashed — operational signals where the alert is a side effect and must never outweigh the primary action.
• Operational truth in tooling. Failed resends stay Failed with a visible Resend button, and ops-notify:test --queue exits non-zero when nothing was queued — this supports CI smoke checks and on-call trust instead of false green.
• Release timing: free. Zero config changes, zero migrations, no breaking changes for normal use — it can ride along with any sprint and does not need a roadmap slot.

When to Consider This Package

Adopt when:

• You're on Laravel with a Redis-backed cache and Horizon (Horizon status is a first-class panel widget, now memoised per request).
• You need chat/topic routing with per-destination thresholds and periodic digests — not just a single webhook.
• Availability of the host request matters more than guaranteed delivery of the alert: the design explicitly prefers a duplicate over a lost alert, and a lost alert over a broken request.
• You want the panel and artisan tooling (test send, chat discovery) instead of shipping your own admin screen.
• You can tolerate pre-2.0 semver and occasional internal API churn — a patch release replaced BurstGuard::pullHeld() with heldCount() + clearHeld().

Look elsewhere when:

• You need at-least-once, auditable delivery with a durable outbox and replayable history — burst suppression and fire-and-forget are the opposite of that.
• You need escalation policies, on-call schedules, ack/resolve workflows. This is a notifier, not an incident tool; that's PagerDuty/Opsgenie territory.
• There's no Redis — dedupe, burst windows, and digests all lean on cache semantics.
• You have compliance retention or PII constraints on alert content.
• You need one vetted vendor for every channel (SMS, voice, email at scale).

Risk to carry forward: a patch release fixed data-loss-class defects — a counter that could lose its TTL and suppress an event forever with no digest, digests swallowed by a DB hiccup, and digests sent to the wrong destination. Fixed is good, but it signals the burst/digest path is young. Pilot it on non-critical alerts before making it the only path for paging.

How to Pitch It (Stakeholders)

For executives: a small, low-risk dependency that makes operational alerting reliable without asking engineering to build and maintain a notifier, a dedupe layer, a digest scheduler, and an admin panel. v1.3.1 is a hardening pass with no migrations, no config changes, and no breaking changes for normal use. It removes the two failure modes that actually cost money: an alerting outage taking down a user-facing request (an unreachable cache used to 500 the request that triggered the alert), and silent alert loss at window boundaries (counters that suppressed an event forever, digests lost to a database hiccup). It also fixes routing so one event fanned out to two chats no longer cross-contaminates counters, and stops the UI reporting "Queued" when nothing was queued.

For engineering: 285 tests, Larastan level 8, and a clear failure-isolation contract — send() logs and sends rather than throwing, and the ops channel no longer aborts Laravel's loop over notifiables and drops database/mail for the remaining recipients. Upgrade is a composer bump; the only internal change is BurstGuard::pullHeld() splitting into heldCount()/clearHeld(), so the blast radius is limited to anyone who extended internals.

For on-call and support: fewer duplicate pages during spikes, digests that report the real held count even after a retry, and a panel whose Resend state can be trusted — so triage time isn't spent chasing phantom retries.

Recommendation: adopt for operational notifications where the alert is a side effect of a user action. Keep it off the critical paging path for one release cycle, then promote it once it has run quietly against non-critical events.