Laravel Failed Job Monitor Laravel Package

Product Decisions This Supports

• Closing the "silent failure" gap in queue-based features. Any roadmap item that depends on background processing—transactional email, exports, billing sync, webhook delivery, image processing, nightly reports, third-party API sync—can fail without a user-facing error. This package gives you a minimum viable detection layer: if a queued job fails, the right people get a mail or Slack notification. That directly supports decisions about whether a feature is "production-ready" from an operational standpoint, not just a functional one.

• Build vs. buy for operational plumbing. The capability is small, well-bounded, MIT-licensed, and maintained by Spatie. Building an internal failed-job listener plus notification routing is not hard, but it is undifferentiated work that must then be maintained across Laravel upgrades. Adopting the package is the "buy" (at zero license cost) and frees engineering effort for domain logic. This is a clear case where the default should be adoption unless a broader observability platform is already in place.

• Prioritizing reliability investment. It helps answer: "Do we invest in alerting now, or wait for a full observability platform?" For teams with no APM, error tracker, or on-call tooling, this is a high-leverage, low-cost first step. It supports sequencing a reliability roadmap: basic failure alerting first, then dashboards/trends/escalation if volume and criticality justify it.

• Alert routing and on-call policy decisions. Configuration supports mail and Slack out of the box, multiple email recipients, a Slack webhook, and a notification filter. That makes it a forcing function for decisions like: which channel is for engineers vs. stakeholders, which failures should page someone, and which should be suppressed. The filter mechanism supports noise-control policy without writing custom alerting code.

• Noise and signal trade-off decisions. Because the default is to notify on every failure, product and engineering can decide whether all failures are actionable or whether filtering is needed by job type, environment, or exception class. That is a product decision about operational attention, not just a technical configuration.

• Graduation criteria for observability spend. Using this package establishes a baseline—time-to-detect a failed job, incident volume, repeat offenders. Those signals inform when to justify budget for Sentry, Datadog, New Relic, Flare, PagerDuty, or a dedicated queue monitoring product. It is a wedge, not a destination.

• Use cases where this is especially relevant: customer-facing async workflows, revenue-affecting jobs, data synchronization with external systems, and any queue where failure means stale or missing data that customers will eventually notice.

When to Consider This Package

Consider adoption when:

• The product runs on Laravel with production queues and has at least one business-relevant background job.
• There is no existing failure-alerting mechanism, or alerting is ad hoc (someone checks Horizon occasionally, or failures are discovered by customer reports).
• The team is small and lean, without a dedicated SRE or observability budget.
• Mail and/or Slack are acceptable alert channels, and simple notification routing is sufficient.
• You want a low-effort, low-risk quick win—installation is a Composer require, a published config file, and a handful of environment variables.
• You need basic filtering (for example, suppress local/staging noise or exclude known-benign job types) but not full alert management.
• You are on a supported stack: PHP 8+ and a current Laravel version (recent releases add Laravel 12/13 compatibility; Laravel 5.8 and 6.x are no longer supported on v4).
• You use Laravel Horizon and want failure notifications with a link back to the Horizon dashboard—there is built-in support for this, with the link hidden when Horizon is not in use.

Look elsewhere when:

• You already have Sentry, Bugsnag, Datadog, New Relic, Flare, or similar capturing exceptions with routing and alert policies. This package would duplicate, not replace, that capability.
• You need deduplication, aggregation, rate limiting, severity tiers, escalation policies, or on-call rotations (PagerDuty, Opsgenie). This package notifies per failure; it does not manage incidents.
• You need dashboards, historical trends, SLA reporting, or backlog/latency/throughput monitoring. This only alerts on job failure—not on queues being slow, stuck, or backing up.
• You need retry orchestration, dead-letter workflows, or per-job retry/backoff policy. Those belong in your queue configuration or a broader platform.
• You have very high-volume queues where per-failure notifications would flood channels and train people to ignore alerts.
• You are polyglot or non-Laravel, or need a single centralized monitoring view across services.
• You require vendor support, SLAs, or compliance guarantees. This is a community open-source package, not a supported commercial product.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed package that closes a real operational blind spot. Today, if a background job fails—an invoice sync, a customer email, a data export—nobody may know until a customer complains. Adopting this package turns that into an automatic Slack or email alert, typically in a few hours of engineering time, with no new infrastructure and no vendor contract. It reduces time-to-detect incidents and lowers the risk of silent data staleness. It is not a full monitoring platform, and it should not be sold as one; it is a pragmatic first step that also generates the data we need to decide whether a larger observability investment is justified.

For engineering: One Composer dependency, a published config, and environment variables for enablement, channels, recipients, and Slack webhook. It hooks into Laravel's native notification system, so it composes with existing notification infrastructure. Extension points are clean: swap in a custom notification class, a custom notifiable, or a notification filter for noise control. It can be disabled in local development, and it integrates with Horizon for direct links to failed jobs. Two caveats worth noting: filters should be implemented as a static callable class rather than a closure if you use config:cache, and the package requires PHP 8+ and a current Laravel version.

Recommendation: Adopt as a standard baseline for production Laravel services with queues. Assign an owner for channel configuration and alert routing, define a filter policy to prevent noise, and set a review point—if failure volume grows or we need aggregation, escalation, or trend reporting, graduate to a full observability platform. Risks are low: limited scope, community-maintained, no built-in deduplication or SLA—so treat it as table stakes, not a complete reliability strategy.