- How do I install and configure guanguans/laravel-exception-notify?
- Install it with Composer using composer require guanguans/laravel-exception-notify, then publish the config file with php artisan vendor:publish and add your webhook URLs and credentials to .env or your secret manager. The package hooks into Laravel's existing exception handling, so no migrations, queue tables, or extra infrastructure are needed. A first channel delivery is typically achievable in well under a day; a full multi-channel, throttled, redacted setup is a small, well-bounded task.
- Which notification channels does laravel-exception-notify support?
- It fans exception reports out to more than 35 channels, including Log, Mail, DingTalk, Feishu/Lark, WeCom/WeWork, Slack, Telegram, Discord, Microsoft Teams, Mattermost, RocketChat, Google Chat, Bark, Ntfy, Pushover, PushDeer, PushPlus, ServerChan, Zulip, and ZohoCliq. Channels are configured in the package config file, and custom channels are supported if you need something not on the list. You can enable multiple channels at once so the same exception reaches several destinations.
- Which Laravel versions does this package support?
- The package attaches to Laravel's built-in exception reporting lifecycle and is aimed at current Laravel releases. Because supported framework constraints live in composer.json and can change between majors, always check the version constraints before upgrading Laravel. The 7.0.4 release is maintenance-only and does not alter supported framework versions, so an existing install stays on the same compatibility contract.
- How does it integrate with Laravel's exception handler?
- It plugs into the framework's existing exception reporting path through the package service provider rather than requiring you to rewrite your Handler class or wrap controllers. When an exception is reported, the package formats the message and dispatches it to each enabled channel. Because it changes no domain code and introduces no persistence layer, the blast radius is narrow and removal is just a config change.
- Will it flood my chat channel with an alert for every exception?
- By default the package reports per exception, so an unthrottled production deployment can produce an alert storm that leads on-call to mute the channel. Size the volume in staging first, then treat throttling configuration as a reviewed artifact rather than an untouched default. Alerting that on-call ignores is worse than no alerting, so set a noise threshold and record who owns it.
- Is it safe to send stack traces and request data to third-party chat tools?
- Exception payloads can include stack traces, request bodies, and headers that carry PII, tokens, or credentials, so data egress is a real compliance concern. Make the redaction decision a prerequisite for production enablement, not a follow-up ticket, and involve security or legal early if regulated data is in scope. Also confirm which channels are approved for production data and who owns the webhook credentials.
- What happens if a webhook is broken or the notifier itself throws?
- A notifier that throws inside the exception handler can mask the original error or degrade error rendering, so gate production enablement on an explicit failure-mode test with a deliberately broken webhook. Verify that the original exception still renders and logs correctly when a channel is unreachable. Do this before turning on every channel, not after the first incident.
- Is laravel-exception-notify production ready and actively maintained?
- It is a small, MIT-licensed, single-maintainer utility with a narrow job; the low star count and maturity score reflect scale, not fit. Release 7.0.4 is maintenance-only: Rector config cleanup and dev-dependency bumps, with no changes to runtime notifier code, the service provider, config schema, or supported framework versions. Mitigate the bus factor by pinning the version and isolating it behind an internal notifier abstraction so a replacement is a config change.
- How does it compare to Sentry, Bugsnag, or an APM platform?
- This is a notification transport, not an observability platform: it answers that something broke and gives you the text, not how many users were affected, when it started, or whether it is getting worse. Position it as the cheap tier and last-mile redundancy layer in an observability roadmap whose later phases, such as grouping and dedup, correlation IDs, dashboards, and on-call rotation, may still be unfunded. Judge it on whether the notification job is worth doing, not as a platform bet.
- How do I know if alerting silently stops working?
- Alert-channel death is silent: a rotated webhook or expired secret means zero alerts and no signal that alerting stopped, which is the most commonly skipped control. Add a dead-man's-switch or heartbeat monitor that expects a periodic test notification and pages when it goes missing. Pair that with an owned checklist for credential rotation so webhook changes are never a surprise.