- How do I install romanzipp/laravel-queue-monitor in a Laravel application?
- Install the package with Composer, then publish and run its migration so the queue monitor table exists in your database. Add the QueueMonitor trait to the job classes you want to record, or enable monitoring for all jobs through the config file. The package also registers a Blade dashboard on a configurable route, so you can browse and filter recorded jobs immediately after migrating. No agent, sidecar, or external service is required.
- Does Laravel Queue Monitor support Laravel 11 and Laravel 12?
- That is not documented in the 5.0.0 release notes, which cover schema, config, and database support changes but do not state illuminate or PHP version constraints. Check the composer.json of the exact tagged release before committing, and run a quick install in a scratch app on your target Laravel version. Because this is a service provider plus a migration and an Eloquent model, incompatibilities are usually shallow, but budget for a small patch or fork if the constraint is tight. Treat framework compatibility as the highest-probability blocker to resolve first.
- What is the difference between Laravel Queue Monitor and Laravel Horizon?
- Horizon manages and monitors queue workers and supervisors, keeping recent job metadata in Redis, while this package writes a durable row per job into your application database. Horizon is not designed to answer whether a job was ever queued and whether it ever started, which is exactly what the new queued_at tracking addresses. Use Horizon for worker health and throughput, and Queue Monitor for job-level record-keeping, debugging, and support investigations. It is not a replacement for Horizon, Sentry, or a metrics pipeline, and it exports no Prometheus metrics, OpenTelemetry spans, or alerting.
- How do I upgrade from version 4 to 5.0 of laravel-queue-monitor?
- Version 5.0 is a major release with a schema change, so it is not a drop-in Composer update. Republish the migrations with the migrations tag, run php artisan migrate to add the new queued_at column, and review the new monitor_queued_jobs config flag, which defaults to on. Scope this as a deliberate piece of work rather than routine dependency hygiene, and verify dispatch behaviour in staging afterwards. A proof of concept takes under a day for one engineer.
- Does queue monitoring add overhead or write amplification to job dispatch?
- Yes, and 5.0 shifts where it lands. Each monitored job now produces a queued write at dispatch time on the web request path, plus the existing start, finish, and fail writes inside the worker, so expect roughly three to four database writes per job across two tiers. All writes go to the same database as your application, which keeps integration cost low but puts telemetry on the hot path of every dispatch. Benchmark against your dispatch volume before enabling it globally on high-throughput producers.
- Will a monitoring failure break job dispatch or cause user-facing errors?
- That is the main blast-radius question with 5.0, because a monitoring row is now written inside the request cycle that dispatches the job rather than only inside the worker. In 4.x a monitor failure could at worst amplify a worker; it can now surface as a user-facing API error or a lost dispatch. Confirm and explicitly test fail-open behaviour, meaning telemetry is dropped and the dispatch proceeds anyway, in staging before production. This should be a forced decision, not an assumption.
- How does the queue monitor dashboard work and can I change its route?
- The package ships a bundled Blade dashboard mounted on a configurable route, so you get searching, filtering, and inspection of failed or completed jobs without building any UI yourself. The route prefix and related UI settings live in the published config file, and the dashboard can be disabled entirely if you only want the underlying records. Records include status, duration, attempts, exceptions, and payloads, which is usually enough to debug a failure without digging through logs. Remember to protect the route with your application's auth middleware, since payloads may contain sensitive data.
- Can I monitor only specific jobs or exclude noisy jobs from being recorded?
- Monitoring of individual job classes is driven by the QueueMonitor trait, so you can apply it only to the jobs you care about. The config file controls package-wide defaults, including the 5.0 monitor_queued_jobs flag that decides whether dispatches are recorded at queue time. In a large application, start narrow with critical jobs and expand once you have measured the write overhead. This keeps the table size and dispatch cost predictable.
- How do I store custom data or search my own fields on monitored jobs?
- The trait exposes hooks on the job class for attaching custom data to a monitored job, which is stored alongside the standard status, duration, attempts, exception, and payload fields. The dashboard then lets you filter and inspect those records, which is typically how teams tag jobs by tenant, customer, or business operation. Use this to make support investigations fast rather than dumping everything into the exception column. Keep custom payloads small, since every field is written multiple times per job lifecycle.
- Do I need a cleanup or pruning strategy for the queue monitor table?
- Yes, all records live in a single table in your application database, so it will grow continuously at three to four rows-worth of writes per monitored job. Schedule a recurring prune of rows older than your retention window, either with your own artisan command or the package's purge command, and index the columns you filter on. Without pruning, dashboard queries and backups slow down on busy queues. Pair this with a deliberate decision about whether payloads need to be retained for compliance reasons.