Laravel Failed Job Monitor Laravel Package

Product Decisions This Supports

• Observability & Reliability: Proactively monitor and resolve job failures in async workflows (e.g., payments, notifications, reports) to reduce MTTR (Mean Time to Recovery) and improve system resilience.
• Developer Experience: Shift from reactive debugging (e.g., checking logs manually) to automated alerts, reducing toil for backend engineers.
• Scalability: Enable teams to safely adopt more complex job queues (e.g., Laravel Horizon) without fear of silent failures.
• Roadmap Prioritization:
  • Build vs. Buy: Avoid reinventing a job-failure notification system (e.g., custom Slack/email logic) when this package provides a battle-tested, configurable solution.
  • Feature Flagging: Use the notificationFilter to gradually roll out monitoring for critical jobs (e.g., only(['SendInvoiceJob', 'ProcessPaymentJob'])).
• Use Cases:
  • Critical Path Jobs: Alert on failures in payment processing, user onboarding, or data migrations.
  • Multi-Environment Awareness: Disable alerts in local environments (via FAILED_JOB_MONITOR_ENABLED) but enable them in staging/production.
  • Custom Integrations: Extend beyond email/Slack (e.g., PagerDuty, Opsgenie) by subclassing the Notification or Notifiable classes.

When to Consider This Package

• Adopt if:
  • Your Laravel app relies on queued jobs (e.g., Horizon, Redis, database queues) and failures are currently undetected or require manual log checks.
  • You need real-time alerts (email/Slack) for job failures without building custom infrastructure.
  • Your team lacks dedicated SRE/DevOps resources to monitor queue workers.
  • You’re using Laravel 8+ (PHP 8+) and want a lightweight, maintained solution.
• Look elsewhere if:
  • You need advanced metrics (e.g., failure rates, latency trends) → Consider Laravel Horizon’s built-in monitoring or Prometheus + Grafana.
  • Your jobs are short-lived (e.g., <1s) and failures are rare → Manual log checks may suffice.
  • You’re on Laravel <5.5 → Use an older version (v3.x) or migrate to a supported stack.
  • You require multi-channel routing (e.g., route failures by job type to different teams) → Extend the Notifiable class or pair with a workflow tool like Temporal.
  • You need retries with exponential backoff → Use Laravel’s native retryAfter() or a package like spatie/laravel-activitylog.

How to Pitch It (Stakeholders)

For Executives/Stakeholders:

"This package turns silent job failures into actionable alerts—reducing downtime and firefighting. For example, if a payment-processing job fails, our team gets an instant Slack/email notification instead of discovering it hours later via support tickets. It’s a 10-minute setup that pays off immediately in reliability. The cost? Zero—it’s open-source and maintained by Spatie, a trusted Laravel partner."

Key Outcomes:

• Fewer outages: Catch failures before users are impacted.
• Faster MTTR: Engineers resolve issues while context is fresh.
• Scalable: Works for 10 jobs or 10,000 without extra effort.

For Engineering Teams:

*"This solves the ‘black box’ problem of queued jobs. Currently, if a job fails, we might not know until a user reports an issue or we manually check logs. This package:

• Automates alerts for failed jobs (email/Slack out of the box).
• Integrates seamlessly with Laravel’s notification system—no reinventing the wheel.
• Supports customization: Filter alerts (e.g., ignore SendWelcomeEmailJob), extend to other channels, or subclass for advanced logic.
• Zero runtime overhead when disabled in dev/staging.

Implementation:

1. Install (composer require spatie/laravel-failed-job-monitor).
2. Configure .env (e.g., FAILED_JOB_EMAILS=team@example.com).
3. Done—alerts work immediately. Extend later as needed (e.g., add PagerDuty).

Tradeoffs:

• Not a replacement for monitoring tools (e.g., Datadog) but fills a critical gap for Laravel apps.
• Requires Laravel 8+ (PHP 8+). If you’re on an older stack, we can discuss alternatives."