- How do I install cerbero/notifiable-exception in a Laravel app?
- Install it like any Laravel package: run composer require cerbero/notifiable-exception, then publish the config file with php artisan vendor:publish. The service provider is registered through Laravel's package auto-discovery, so there is no bespoke bootstrapping to write. After that you define your exception classes and map them to notifiables in the published config.
- Which Laravel and PHP versions does this package support?
- Check the Composer constraints against your target framework before committing, because the repository's release history predates current Laravel majors. The evaluation flags Laravel 10, 11 and 12 compatibility as the single largest unknown, and the near-zero dependent count means the ecosystem has not validated it against modern versions. Run a smoke test in staging on your exact Laravel and PHP versions first.
- How do I send a Slack notification when a custom exception is thrown?
- Create an exception class that exposes via() and toSlack() methods, following the same channel conventions as any Laravel notification. Register that exception class in the package config along with the notifiables that should receive it. When the exception is thrown, the package routes it through the Notification facade to those channels.
- Can I control which exceptions trigger notifications and who receives them?
- Yes. The config exposes default notifiables, an enabled/disabled toggle and a should-notify conditional that decides whether a given exception should alert at all. Dispatch is limited to the exception types you explicitly map rather than every 500 the application produces. It is a routing layer, not a catch-all error reporter.
- How do I queue exception notifications so they don't block the request?
- Have your exception notification implement ShouldQueue so the mail or Slack HTTP call runs on a worker instead of inside request handling. Without queueing, SMTP and Slack latency land directly in the exception path and slow down or destabilize the response. Confirm queueing works end-to-end through the notification pipeline and monitor failed jobs, since a failed job should not silently swallow the alert.
- Does the package deduplicate or throttle repeated exception notifications?
- There is no inherent deduplication, throttling or sampling, so an exception thrown in a hot loop produces one notification per throw. Without an extra rate-limiting layer this becomes an outage amplifier rather than a detector. Use Laravel's RateLimiter, a channel-level throttle or queue coalescing to avoid flooding the same audience.
- What happens if the notification driver fails while handling an exception?
- Dispatch happens in the exception path, so a failing notification driver can itself throw. Depending on the implementation this can produce recursive alerting or replace the original exception with a transport error, destroying the diagnostic signal you were trying to capture. Confirm the guards in the package source rather than assuming failures are swallowed or logged.
- How do I stop sensitive data leaking into exception notifications?
- Exception context sent to Slack or email routinely carries request payloads, headers and stack traces, which can include PII, credentials or internal topology. Define an explicit redaction policy and sanitize the context your notification methods render before enabling the package in production. Treat every outbound channel as a trust boundary crossing.
- Does it work alongside Sentry, Bugsnag or Flare and Laravel 11's withExceptions API?
- It is a routing layer that maps exception types to notification channels, so it complements rather than replaces an error tracker like Sentry, Bugsnag or Flare. The open question is whether it coexists cleanly with Laravel 11's withExceptions / Exceptions::report() API or shadows part of that flow. Test it next to your existing integration before rolling it out.
- Is cerbero/notifiable-exception actively maintained and safe for production?
- It is a small, MIT-licensed, single-maintainer package with low activity and no dependents, so treat it as a planned fork or vendor candidate. The codebase is only a few hundred lines, which makes vendoring practical. Pin the version, review the source for the recursion and Laravel-version concerns above, and make that decision deliberately rather than reactively.