Laravel Queue Monitor Laravel Package

Product Decisions This Supports

• Build vs. buy for queue observability. Every Laravel product eventually asks "did that job actually run?" A DIY job_logs table plus a Blade dashboard is a ~1–2 week build that then needs ongoing ownership (retention, pruning, UI, pagination, exception capture). This package is a credible "buy" (MIT, zero cost) that removes that build from the roadmap and lets the team spend the sprint on customer-facing work instead.
• Dispatch vs. execution triage. As of 5.0 the package records queued_at at dispatch time in addition to the lifecycle events, so "never dispatched," "dispatched but sat in the queue," and "ran and failed" become three distinguishable states instead of one opaque "it didn't work." That is the single most common ambiguity in support escalations on async flows, and it now resolves in a SQL query rather than an engineering investigation.
• Capacity and backlog decisions. Time-in-queue (dispatch → processing start) is now a first-class metric, separate from job duration. Backlog growth, worker starvation, and "our exports are slow because they wait 6 minutes" become measurable and arguable in roadmap terms, not anecdote — and it tells you whether to add workers, split queues, or move a queue off the database driver.
• Reliability investment prioritization. Persistent per-job history (queued → processing → processed/failed, attempts, duration, exception payload) gives you the data to argue which queues deserve engineering time: e.g. "18% of billing jobs failed and were retried this week" is a far stronger roadmap input than anecdote.
• Support and SLA decisions. Support can self-serve "your export is still processing / failed at 14:02 with this error" instead of escalating to engineering. With dispatch-time visibility they can also say "we never received the request," which changes the escalation path entirely. That directly informs whether you staff a tier-1 queue triage runbook, and shortens time-to-resolution on async flows (emails, webhooks, exports, invoice generation, media processing).
• Alerting and DLQ roadmap. Once failures are queryable in SQL, "notify on N consecutive failures per queue," "alert when queue wait exceeds X," or "surface failed-job count in the admin panel" become small, well-scoped features rather than speculative architecture. It also gives you a concrete failure corpus to justify (or dismiss) a dead-letter queue design.
• Architecture decisions with evidence. Duration, queue-wait, and throughput data per queue informs worker concurrency, queue splitting, timeout tuning, and whether a given queue needs Horizon/Redis or is fine on the database driver.
• Customer-facing status surfaces. Eloquent models plus JSON API endpoints mean a "your report is ready" widget or an internal ops console can be built on the same data without new infrastructure — a cheap differentiator for onboarding-heavy or batch-processing products.
• Retention, compliance, and PII policy. Because records live in your database, retention windows and exception-payload scrubbing become an explicit product policy decision (and a GDPR talking point) rather than something dictated by a vendor's data plane.

When to Consider This Package

Adopt when:

• You run Laravel queues (database, Redis, SQS, or mixed) carrying business-critical work where silent failure is a revenue or trust problem.
• You need to distinguish "job was never dispatched" from "job was dispatched and didn't finish" — 5.0's queued-job monitoring covers this, and it is the distinction most support tickets actually hinge on.
• You have no APM budget, or APM coverage is host/metric-based and cannot answer "show me this specific job's history."
• You want job records joinable to application data (orders, tenants, users) in SQL — a real advantage over log-only or metrics-only tooling.
• You need per-job audit history for a support workflow, an admin console, or a regulated process.
• You run PostgreSQL or SQLite (5.0 adds both), or want dev/test parity against SQLite while production runs Postgres/MySQL.
• The team is small and would rather configure a package than own an internal dashboard.

Look elsewhere or descope when:

• You already run Horizon on Redis — it covers metrics and a UI. Overlap is real; add this only if you specifically need persistent per-job history retained in SQL beyond Horizon's window, or dispatch-time records that outlive Redis.
• You need distributed tracing across services, log correlation, or real-time paging. Pair with Sentry/Datadog/OpenTelemetry instead; this is not an incident-response tool.
• Throughput is high (roughly 100k+ jobs/day). Note that 5.0's queued-job monitoring is on by default and writes a row at dispatch in addition to lifecycle updates — that increases write amplification on your primary database. Require sampling, a separate connection, or disabling monitor_queued_jobs before adopting at volume.
• You need active maintainer support, SLAs, or guaranteed security patches. 5.0 is real evidence of maintained velocity and softens the earlier "stale release" concern, but a new major after a quiet period does not by itself guarantee a release cadence — still treat it as internal-ownership software (fork, vendor, or budget maintenance time).
• You cannot absorb a breaking upgrade: 5.0 requires publishing new migrations (a queued_at column), running them, and an explicit decision on the new monitor_queued_jobs default before deploying to production.
• Data residency or PII rules forbid exception payloads sitting in a general application table without a scrubbing plan.

How to Pitch It (Stakeholders)

To executives: We have no reliable way to answer "did the customer's job run?" today, which turns async failures into support tickets and occasionally silent revenue loss. This is a free, MIT-licensed Laravel package that records every job's lifecycle in our existing database and gives us a dashboard plus API in days, not a quarter. The new 5.0 release lets us also prove whether a job was ever handed to the queue at all, adds support for the databases we already run, and demonstrates the project is actively developed rather than abandoned. It replaces either a homegrown build we'd have to maintain forever or a per-host APM contract, and it's fully reversible — one migration and one config file. The caveat is that 5.0 is a breaking upgrade and we should treat adoption as "adopt and own," with a short compatibility spike before we commit.

To engineering: Drop-in, event-driven, no new infrastructure. It hooks Laravel's queue events, writes to a queue_monitor table, and exposes Eloquent models, API endpoints, and a Blade dashboard; queues monitored, sampling, and retention are configurable. 5.0 adds queued-job monitoring (new queued_at column, monitor_queued_jobs config defaulting to on), plus PostgreSQL and SQLite support. What we're asking for: a one-day spike to confirm compatibility with our Laravel/PHP version and to run the 5.0 migration path, a decision on whether to keep monitor_queued_jobs enabled given the extra write per dispatch, a decision on a dedicated DB connection and retention/pruning job, and an explicit note that this complements Horizon/Telescope rather than replacing them. Known costs: per-lifecycle DB writes (higher now that dispatch is recorded — mitigate with sampling or a separate connection at volume) and the likelihood we fork it if upstream goes quiet again.