Laravel Log Alarm Laravel Package

Product Decisions This Supports

• Build vs. buy for alerting on our Laravel services. This package is a zero-infrastructure way to answer one question — "is the app throwing errors right now?" — without procuring Sentry, Datadog, or a CloudWatch pipeline. It makes the cheapest possible version of that decision reversible: a composer require today, a composer remove if we outgrow it.
• Closing the "we only find out when a customer emails us" gap. For any Laravel app we operate without on-call tooling, this converts a latent reliability risk into a routed notification in Slack, email, Telegram, or Discord. That is a support-cost and incident-duration decision, not an engineering nicety.
• Scoping a monitoring investment tier. Use it to segment the portfolio: apps where a threshold-on-error-count alert is sufficient get this package; apps where we need trace correlation, escalation policies, or cross-service aggregation get a funded observability line item. It draws the line between "must pay for observability" and "must not."
• Alert noise policy as an explicit product decision. Frequency control (LA_LOG_TIME_FRAME, LA_LOG_PER_TIME_FRAME, LA_DELAY_BETWEEN_ALARMS) and string targeting (LA_SPECIFIC_STRING) make notification volume a tunable we own. That is the lever that determines whether the team trusts the channel or mutes it — and a muted channel is worse than none.
• Prioritizing which errors deserve a human. LA_SPECIFIC_STRING lets us alarm on known-bad signatures (deadlocks, payment gateway failures, queue errors) rather than every error line, which is a roadmap-level statement about what "healthy" means for a given product.
• Roadmap input on reliability features. Adoption would surface the next asks — per-endpoint thresholds, severity routing, deduplication across replicas, error grouping. Those become candidates for either a paid tier or an in-house replacement, and this package is a cheap way to generate the evidence before committing budget.
• Due-diligence posture on new dependencies. With zero dependents, a single-primary-maintainer release history, and only a README plus changelog as maturity signals, adopting it is also a decision about accepting a small, thinly-vetted dependency into our supply chain.

When to Consider This Package

Adopt when all of these hold:

• The application is Laravel (declared PHP >= 7 / Laravel >= 5, but treat that as an unverified claim — confirm against our exact PHP, Laravel, Monolog channel, and cache driver versions before committing).
• We have no existing error alerting, or the existing alerting is too expensive or too heavy for this particular app.
• A "N errors of type X within M minutes" rule is an adequate definition of "something is wrong." This is a threshold counter, not an anomaly detector.
• One Slack channel, email list, or Telegram/Discord chat is an acceptable routing destination — no escalation tiers, no on-call rotation, no per-service ownership.
• We are willing to treat the .env alert thresholds as a governed on-call policy artifact with a written decision record and change control, rather than a per-developer toggle.
• Someone owns the tradeoff that alerts live and die with the application process: if the app is down hard enough to stop writing logs, this package is silent. Pair it with an external uptime check or accept that blind spot knowingly.

Look elsewhere when:

• The estate is polyglot, microservice-based, or needs cross-service aggregation, trace correlation, or error grouping — this is a gap-filler relative to Sentry/Datadog/CloudWatch, not a substitute.
• We need escalation policies, severity-based routing, on-call schedules, or alert acknowledgement workflows.
• The app runs multi-replica and we need deduplicated alerting across instances; cache-based counters are per-cache-store and the semantics under a shared cache are worth validating rather than assuming.
• Compliance, audit, or retention requirements demand durable alert history — cache-based tracking is deliberately ephemeral and the published migration appears vestigial.
• The team cannot absorb an unmaintained-dependency risk: one primary maintainer, no evidenced CI matrix, 269 stars, and zero dependents means if it stalls, we fork or replace it ourselves.
• We already have logging infrastructure that can do this natively — a Monolog handler or a log-driver-to-alerting-rule in our existing platform is fewer moving parts.

How to Pitch It (Stakeholders)

To executives: We can add real-time error alerting to our Laravel applications for roughly half a day of engineering and zero new infrastructure spend. Today, errors in these apps are discovered by users. This package watches the logs and posts to Slack or email when an error crosses a threshold we set, with noise controls so the channel stays credible. It is MIT-licensed and removable in one command, so the downside is bounded. It is not a replacement for a full observability platform — it is the cheapest responsible baseline until one is justified, and it gives us the incident data to make that larger investment case.

To engineering: A single-purpose, in-process package that hooks Laravel's log event pipeline, increments counters in cache, and fans out to Slack/email/Telegram/Discord once thresholds are crossed within a time window. No queue worker, no sidecar, no database overhead. Integration is composer require, vendor:publish, a handful of env vars, and a five-error smoke test in Tinker. Two caveats we own: the declared PHP/Laravel support range is implausibly broad and unverified, so we test against our actual versions and Monolog setup; and the alert policy lives in .env, so it goes through change control, not individual edits. It also only alerts while the app is alive to write logs — we pair it with an external uptime check.

Ask: Approval for a one-day spike to validate against our stack and one or two apps, with a go/no-go recommendation and a documented alert-policy default. If it validates, we roll it to the remaining Laravel apps without alerting and revisit paid observability only when we hit the documented ceiling.