Features · Monitoring · Queue Monitoring
Monitoring · Queue Monitoring

Wait, throughput, failures —
the three numbers that matter.

Laravel queues, raw Redis lists, database-backed queues, SQS — discovered when possible, configured when not. Wait time and failure rate alerted out of the box; throughput charted for capacity work.

queues · last 5 min
default wait p95 1.2s · 340/s
emails wait p95 0.4s · 120/s
image-resize wait p95 2.1s · fail 4.2%
webhooks wait p95 0.2s · 88/s
backlog oldest image-resize · 12s
— Why this matters

A queue that is backing up looks fine from the outside.

01

Depth alone is not the signal.

A thousand jobs moving fast is healthy. Fifty jobs that have not moved in ten minutes is not.

02

Every framework names it differently.

Laravel, BullMQ, Sidekiq and Celery all live in Redis with their own conventions. Detection handles the difference so you do not have to.

— What's included

What is tracked per queue.

Size over time
Per queue, with history rather than a current number.
Framework patterns
Laravel, BullMQ, Sidekiq and Celery recognised in Redis.
Push your own
An external metrics API for queues we cannot see.
Dashboard
Per queue, with the history behind it.
— What it looks like

Depth is the number that matters.

7 jobs alert depth 40
Example view · queue default · last 2 h · a worker died at 14:10 and was restarted at 14:38
— Works with

Connected capabilities

— FAQ

Questions, answered honestly.

Which queue systems are supported? +
Laravel (Redis, database, beanstalkd), raw Redis lists, AWS SQS, Sidekiq, BullMQ. Custom backends via the metrics API.
Do you read job payloads? +
No — only meta (job class, queue name, attempt count, exception class). Payload bodies stay on the host.
How does it discover queues? +
Laravel apps via the config file the agent finds; raw Redis by walking key patterns; SQS by region+account on the integration.

See the backlog before customers do.

Queue monitoring included from Starter.

Get early access Back to Monitoring