Laravel Discord Logger Laravel Package

Product Decisions This Supports

Alert-path reliability and primary-vs-secondary alerting. v2.2.1 closes the most consequential gap in this package: a misconfigured or revoked Discord webhook (HTTP 404/401/400) previously failed silently, so the channel looked healthy while zero alerts were delivered. The failure is now written — with the payload redacted — to a configurable fallback_channel. This directly supports a decision to treat Discord as a secondary/notification alert path rather than the only one, and to require an ops runbook entry for "who watches the fallback channel."

Build vs buy for error alerting. Building equivalent behaviour in-house means a custom Monolog handler, batching, truncation, redaction, retry/backoff, and now 4xx error surfacing. This package is a small, bounded dependency that gets you ~90% of that for near-zero engineering time — the right call unless you need routing rules, escalation, or audit-grade retention.

Scope decisions: which environments and log levels get shipped. The fallback-channel feature implies you should decide explicitly where Discord logging is enabled (production only vs. staging too) and at which levels (error/critical only recommended). A noisy channel is an ignored channel; that's a product/ops decision this package forces you to make.

Secret-rotation hygiene. A rotated-but-not-updated webhook token now produces a visible 404/401 rather than silent data loss, which is a concrete argument for scheduling token rotation and monitoring the fallback as a rotation canary.

Non-goals to confirm in the roadmap. This is a notifier, not a log store: no retention, no query, no compliance story. Do not let it become the audit trail.

Upgrade decision (v2.2.1). Patch release, no breaking changes, no config migration required — safe to bump. The only behavioural change is new output to the fallback channel, so verify that channel exists and is monitored before rolling out, since DISCORD_LOGGER_FALLBACK_CHANNEL=single must be set (or the messages still go unseen — an easy footgun to miss).

When to Consider This Package

Adopt when:

• The team already lives in Discord and wants error notifications where they actually read them.
• The app is small-to-mid volume — low error rates, internal tools, side projects, staging, MVPs, small SaaS.
• You want a fast, cheap secondary alert fanout without PagerDuty/Slack/Datadog spend.
• You can accept best-effort delivery (Discord webhook rate limits, payload size caps, no retry queue guarantees) and you have somewhere else to look for the full log.
• You will actually configure and monitor the fallback_channel — otherwise v2.2.1's fix is moot.

Look elsewhere when:

• You need paging, escalation, on-call rotation, or acknowledgement — use PagerDuty/Opsgenie (optionally with Discord as a display channel).
• Volume is high or bursty (exception storms will hit Discord's ~30 req/min webhook rate limit and drop messages); use a real log aggregator.
• You have compliance, audit-retention, or PII constraints requiring durable, queryable, access-controlled logs.
• You need multi-channel routing, severity-based fanout, or structured querying — a logging platform plus this as a thin sink is the better architecture.
• Discord is not a supported communication tool in your org; the dependency is the channel, not the code.

How to Pitch It (Stakeholders)

To executives (one paragraph): We're evaluating a small, low-cost Laravel add-on that pushes application errors into our Discord channel so problems get noticed and triaged faster without paying for an enterprise monitoring suite. The latest patch fixes a real reliability hole: if the Discord connection broke, alerts used to disappear without warning — now the failure itself is reported to a backup channel. It's a notification convenience, not a system of record, and it carries no meaningful cost or lock-in. Recommendation: adopt for non-critical and secondary alerting; keep the paid/durable logging stack for anything we'd need to audit or page on.

To engineering (bullets):

• One dependency, one config file, one webhook URL — a Monolog handler that ships configured log levels to a Discord webhook.
• v2.2.1 is a patch: no breaking changes, no migration. It surfaces Discord 4xx responses (deleted webhook, bad token, invalid payload) with redacted context to fallback_channel instead of swallowing them; set DISCORD_LOGGER_FALLBACK_CHANNEL=single to see them.
• Treat delivery as best-effort: Discord enforces webhook rate limits and payload caps, so batch/truncate and restrict to error/critical in production.
• Don't route PII or high-cardinality context through it; rely on the package's redaction and keep the real log in our log store.
• Action items on adoption: create the fallback channel, alert on it, document webhook rotation, and confirm log-level config per environment.