Notify Exceptions Laravel Package

Getting Started

Treat this as a legacy package. It is archived, last released in January 2022, and has essentially no adoption. Before adding it to a new project, confirm it still installs against your Laravel/PHP version with composer require dragon-code/notify-exceptions; if it conflicts, do not fight it—use Laravel’s native exception reporting plus Notification instead.

Minimal setup:

1. Install with Composer.
2. Publish the package config using the package’s README/provider tag, or run php artisan vendor:publish and select the notify-exceptions entry.
3. Open config/notify-exceptions.php first. That file is the source of truth for enabled channels, recipients, and message formatting.
4. Put recipients and secrets in .env—admin email, chat webhook, bot token, etc.—not directly in config.
5. Enable the package only for production/staging, then clear config: php artisan config:clear.
6. Trigger a deliberate exception in staging and confirm the administrator receives it.

The first practical use case is production 500 monitoring: an unhandled exception in a request, queue job, or scheduled task should notify the on-call admin through email or a chat channel. Check the package README and vendor/dragon-code/notify-exceptions/ next; if the package does not auto-hook into Laravel’s exception handler, wire it from App\Exceptions\Handler::register() using reportable().

Implementation Patterns

Use the package as a reporting side-channel, not as your rendering path. Notify from the exception handler’s report()/reportable() flow so the user still receives the normal HTTP response.

public function register(): void
{
    $this->reportable(function (Throwable $e) {
        // If the package exposes a notifier/hook, call it here.
        // Otherwise keep the package out of the hot path and use Laravel notifications.
    });
}

Day-to-day patterns that work well:

• Filter expected exceptions. Validation errors, authentication failures, 404s, and business-rule exceptions should not page anyone. Keep them in Laravel’s $dontReport list or the package’s ignore configuration.
• Add operational context. Include request ID, user ID, route, environment, app version, and queue/job name when available. An alert without “where” and “who” is usually noise.
• Route by severity. Critical exceptions go to email/pager; lower-severity issues go to a chat channel. Use separate recipients for different channels.
• Throttle and deduplicate. A broken loop can send hundreds of identical alerts. Deduplicate by exception class + message + file + line within a time window, or sample notifications.
• Queue delivery. Sending mail or hitting a webhook inside the exception handler can slow or break error handling. Queue the notification and ensure failed queue jobs are logged.
• Test in staging. Use MAIL_MAILER=log or Mailpit locally, then send one real notification from staging before enabling production.
• Keep a fallback. Always log the original exception through Laravel’s logger even if the notification channel fails. The package should never be the only record of an error.

Gotchas and Tips

• Archived package risk. The last release is from 2022. It may not support newer Laravel or PHP versions, and there is no maintainer to fix issues. Pin the version, check Composer constraints, and be prepared to fork or replace it.
• Recursion is the classic failure. If the notification channel itself throws—bad webhook URL, SMTP timeout, missing token—you can trigger another exception inside exception handling. Wrap notification calls in try/catch, log the failure, and never rethrow from the notifier.
• Do not leak sensitive data. Exception messages and stack traces can contain SQL, credentials, PII, or request payloads. Scrub or limit what goes to email/chat, especially in multi-tenant apps.
• Config cache bites. After changing .env or package config, run php artisan config:clear and rebuild with php artisan config:cache. Queued workers may keep old config until restarted.
• Mail and chat rate limits. A production incident can produce a burst of alerts. Use a transactional mail provider, set a sane From address, and throttle chat webhooks.
• Report, don’t render. Notify in report()/reportable(), not in render(). Rendering should only decide the HTTP response.
• Queue workers matter. If notifications are queued, a down worker means no alerts. Monitor failed jobs and consider a sync path for critical alerts only.
• Use extension points deliberately. Laravel notification channels, custom message formatters, and ignore lists are better extension points than editing vendor code. Wrap the package behind your own small notifier service so replacing it later is cheap.
• Debugging checklist: inspect storage/logs/laravel.log, check config('notify-exceptions') in php artisan tinker, verify the queue worker, confirm the channel credentials, and throw a controlled exception in staging. If the package exposes a test command, use it; otherwise a deliberate throw new RuntimeException('notify-exceptions test') is the quickest end-to-end check.