Watch the queue before it backs up.
A backed-up queue is easy to miss until messages pile up and users feel the delay. Have a small cron check read the depth with redis-cli, rabbitmqctl, or the AWS CLI and call PocketAlert, and a stalled worker lands on your phone in under a second.
Catch the backlog while it is small
A one-line depth check in cron calls PocketAlert. It turns a number you would never watch into a push notification you can act on.
Depth thresholds
A threshold in your cron script fires the alert once depth drifts past the line you set.
Stall detection
A runaway backlog or a fully stalled consumer sends a push while a brief blip stays under the line.
Depth in the message
Drop the queue name and current depth straight into the title and message of the call.
Any broker
redis-cli LLEN, rabbitmqctl list_queues, and the AWS CLI for SQS all return a number you can send on.
Per-queue channels
Each queue gets its own application_id, so payments and email never blur together.
Sub-second delivery
The push lands in under a second, fast enough to act before the backlog snowballs.
Three steps to queue alerts
Measure the queue
Read the queue depth in a cron script with redis-cli LLEN, rabbitmqctl, or the AWS CLI.
Fire on threshold
Call pocketalert send (or curl the messages API) when depth crosses your threshold.
Act in time
Your phone buzzes within a second. Drain the backlog before users notice.
Alert on a backed-up queue
Redis list depth (LLEN)
A tiny cron script reads the depth and calls the CLI once it crosses your threshold:
* * * * * depth=$(redis-cli LLEN queue:emails); \
[ "$depth" -gt 10000 ] && pocketalert send \
-t "Queue backed up" -m "emails: $depth pending"RabbitMQ queue length
* * * * * depth=$(rabbitmqctl list_queues -p / name messages | awk '$1=="emails"{print $2}'); \
[ "$depth" -gt 10000 ] && pocketalert send \
-t "Queue backed up" -m "emails: $depth messages"SQS approximate depth via the API
depth=$(aws sqs get-queue-attributes --queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages \
--query 'Attributes.ApproximateNumberOfMessages' --output text)
[ "$depth" -gt 10000 ] && curl -X POST "https://api.pocketalert.app/v1/messages" \
-H "Token: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"title\":\"Queue backed up\",\"message\":\"orders: $depth pending\",\"level\":\"critical\"}"Give each queue its own application_id so payments and email land in separate channels. The docs cover targeting and per-application channels.
Questions, answered
Run a small cron script that reads the queue depth and calls `pocketalert send` (or curls the messages API) when it crosses your threshold. Works with Redis `LLEN`, RabbitMQ `list_queues`, and SQS `ApproximateNumberOfMessages`.
Set the threshold in the script. A short, recoverable backlog never crosses the line, so only a genuine stall or a runaway depth sends a push notification.
Any broker you can query from the shell works. `redis-cli LLEN queue:emails`, `rabbitmqctl list_queues`, or the AWS CLI for SQS all return a number you can compare and send on.
Put the queue name and the current depth straight into the title and message of the call, so the push reads `emails: 18420 pending` with no extra glue code.
Pass a different `application_id` per queue. The emails queue and the payments worker land in separate channels, so you read the alert and know where to look.
Yes. Give the alert `level=critical` and Android posts it on a channel that bypasses Do Not Disturb, while iPhone shows it as a time-sensitive notification that breaks through Focus. If you also push routine depth reports, send those with `level=silent` so they land in history without a buzz.
Know when the queue falls behind.
Point your monitor or a small depth check at PocketAlert and catch the backlog before users do.