Laravel Exception Notify Laravel Package

Product Decisions This Supports

• Time-to-detection as a launch gate. This package answers the question "can we find out about a production error before a customer tells us?" without procuring an observability vendor. It routes Laravel exceptions into the channels the team already watches (DingTalk, WeCom, Feishu, Slack, Telegram, Bark, email), so it directly supports a go/no-go decision on shipping to real users.
• Build vs. buy vs. adopt-open-source. It is the cheapest credible tier in an alerting strategy: a config file and an afternoon of engineering versus weeks of hand-rolling a report() override plus per-provider webhook clients. Frame the comparison as three options — in-house plumbing, this package, or a paid APM (Sentry/Bugsnag/Rollbar) — and be explicit that this package buys the notification loop, not diagnostics.
• Sequencing the observability roadmap. It lets you ship a working alert path now and defer correlation IDs, dashboards, stack-trace grouping, dedup at scale, and on-call rotations to a later phase with evidence (measured alert volume) rather than guesswork. It gives the roadmap a real "v1" to iterate from.
• Deferring the chat-platform standardization decision. Because channels are pluggable and include China-region tools most SaaS vendors handle poorly, you can ship alerts before the company resolves "Slack or Feishu or WeCom" — relevant during re-orgs, M&A, or multi-region teams.
• Noise policy as a product decision, not an accident. The package ships throttling, environment filters, and message formatting, which turns "how loud should alerting be?" into an explicit, configurable product setting the PM can own and tune after a staging trial.
• Risk register input. It surfaces real product risks early — PII in stack traces leaving the perimeter, single-maintainer bus factor, channel credentials silently expiring — each of which needs a decision and an owner before, not after, production enablement.
• Version posture (7.0.4). No product implication: the release is dev-dependency bumps and Rector config cleanup, with no runtime, API, or config changes. Treat it as a safe patch upgrade that can ride along with routine maintenance.

When to Consider This Package

Consider it when:

• The product runs on Laravel and currently has no alerting beyond log files — the gap is "nobody knows until a user complains."
• You need fast, cheap, reversible: install, publish one config file, set a webhook secret, scope to production, done.
• Multi-channel or China-region coverage matters (DingTalk, Feishu, WeCom) and mainstream SaaS tooling fits poorly.
• You want a redundant last-mile alert path alongside a paid APM, or a stopgap while procurement runs.
• Alert volume is modest and notification-level throttling is an acceptable substitute for real aggregation and dedup.
• You're replacing scattered Log::critical + mail or bespoke webhook calls, and want that logic centralized in config rather than smeared across the codebase.

Look elsewhere when:

• You need traces, breadcrumbs, release health, or grouping at scale — that's Sentry/Bugsnag territory. This package notifies; it does not diagnose.
• You require vendor SLAs, security review artifacts, or a supported enterprise contract. This is a single-maintainer, MIT-licensed project.
• Traffic is high or spiky: notification volume scales with exception volume, precisely when the system is least healthy, and an unthrottled setup can hit provider rate limits in minutes and get the webhook blocked.
• You handle regulated data and cannot yet redact exception payloads before they hit third-party webhooks.
• On-call maturity is low and there's no owner: an unmuted but unread channel is worse than no channel, because it creates false confidence.

Gate to pass before committing: a named internal owner for config, credentials, and channel inventory; a documented redaction decision; and a staging trial that measures actual daily notification volume.

How to Pitch It (Stakeholders)

To executives: "It's a one-day integration that puts production error alerts into the chat tool we already use, at zero licence cost. Today, failures go unnoticed until a customer reports them; this closes that window. It is deliberately a bridge, not a replacement for paid monitoring — it buys us a safety net now while we make the vendor decision next planning cycle. The main risk is that it's maintained by a single author, so we'll pin the version and keep it behind our own thin notifier layer, which makes swapping it out a configuration change rather than a refactor."

To engineering: "It hooks Laravel's exception handler and fans out to chat/email channels via a single published config. Custom channels, message shaping, environment filters, and throttling are all supported out of the box — no migrations, no queue tables, no services to provision. Effort to first channel is hours, not days. Three things to respect: code running inside the exception handler is the riskiest place in the app, so wrap notifier failures and test with a deliberately broken webhook URL; per-exception notification is an alert-storm amplifier, so enable throttling and queueing from day one; and stack traces can carry PII, so settle redaction before production. Keep channel lists and payload shape in config, not in application code, and don't rip out existing alerting in the same change that introduces this — run it additively and only then retire the old Log-based path."

How we'll know it worked: measurable time-to-detection in staging, a daily notification volume the on-call channel tolerates without muting, and a documented runbook covering which channels are live, who owns the credentials, and how to disable a channel mid-incident.