- What does spokospace/filament-ops-notify do?
- It adds operational alerting to Laravel applications with Filament admin panels, sending inquiry, error, and build events to Telegram. The package provides a facade-style sender, a Laravel notification channel, burst protection, digests of suppressed volume, chat-destination discovery, and an artisan self-test command.
- How do I install and configure filament-ops-notify in a Laravel Filament panel?
- Install it with Composer and follow the package README to register the service provider and configure Telegram bot credentials and chat destinations. The v1.3.1 notes state that normal use requires no migrations, config changes, or breaking changes. After configuration you can send alerts with OpsMessage::send() or route them through Laravel notifications using the ops channel.
- Which Laravel and PHP versions does this package support?
- The provided evaluation does not pin exact Laravel or PHP versions, so check the package composer.json constraints before adopting it. It targets Laravel applications that run Filament panels and relies on standard Laravel cache, queue, scheduler, and database features. Confirm the constraints against your application's PHP and Laravel versions in CI.
- How do I send an ops notification to Telegram with OpsMessage::send()?
- Use the facade-style sender, for example OpsMessage::send(), to dispatch an operational alert from your application code. You can also send through Laravel's notification system using the package's custom ops notification channel. Configure the Telegram destinations first so the package knows where to deliver each message.
- How does the burst guard work and how do I tune alert thresholds?
- The burst guard rate-limits alerts per event and per destination using cache-backed counters and TTLs. In v1.3.1 the burst key includes the destination, so one event fanned out to multiple chats or topics now keeps independent counters. If you tuned thresholds against older behavior, re-baseline them because multi-destination events can fire more often.
- What happens to dedupe and alerts if the cache is unavailable?
- Version 1.3.1 makes the alerting path fail-open: if the cache is unreachable, the package logs and sends anyway instead of throwing into the host request. This shifts behavior toward at-least-once delivery, so duplicate alerts can occur during a cache outage. Check downstream consumers that assume alert uniqueness and set your noise tolerance accordingly.
- Which cache drivers are supported for dedupe and burst limiting?
- The dedupe and burst logic depends on atomic Cache::add and increment behavior with TTL re-arming, so Redis and Memcached are the safe assumptions. The evaluation flags the database cache driver as needing confirmation, either as supported or explicitly out of scope. Verify your chosen cache driver before relying on burst guarantees in production.
- How do I test Telegram ops notifications with ops-notify:test?
- Run php artisan ops-notify:test to exercise the Telegram ops notification path from the operator panel or CLI. With --queue, the command returns a non-zero exit code when nothing was queued, which is useful in scripts. This self-test helps confirm bot credentials, destinations, and delivery without waiting for a real inquiry or build event.
- What changed in v1.3.1 and is the upgrade safe?
- The v1.3.1 upgrade is low risk for normal use because there are no schema or config deltas and the release notes report a 285-test, Larastan level 8 baseline. The internal BurstGuard API changed from pullHeld() to heldCount() plus clearHeld(), so grep for subclasses, decorators, or reflection before merging. Also note fail-open cache behavior, destination-scoped burst keys, honest resend Failed reporting, and a longer chat-discovery lock.
- Is filament-ops-notify suitable for production and what maintenance should I expect?
- It is technically suitable for production when you accept dependencies on cache, queue, scheduler, and database, and you validate the cache driver and worker timeouts. The evaluation rates upgrade risk low but flags at-least-once semantics during cache outages and a chat-discovery lock held for the whole paged scan, roughly 100 seconds worst case. Ask whether the package has an owner and SLA or is effectively unowned infrastructure, and confirm the digest retry policy before depending on it for paging.