Guide
The Queue API allows modules to defer work: email sending, image derivative generation, search indexing, external API calls, and batch operations. Items are added to a queue and processed by queue workers - typically during cron.
When a Drupal queue is not processing, items pile up. The admin UI may show that a newsletter was “sent” - because it was queued. But it was never actually delivered.
drush queue:list
Shows queue names and item counts. If a queue has thousands of items and the number keeps growing, the Drupal queue is not processing correctly.
drush queue:run queue_name
Manually processes a queue. If it throws errors, you’ve found the problem. But this is reactive, not proactive.
Logystera tracks queue processing as log events: items added, items processed, items failed, processing duration. The processor derives metrics: queue depth over time, processing rate, failure rate per queue.
What Logystera tracks:
A Drupal site used the Queue API for sending newsletter batches and generating image derivatives. A configuration change moved cron to an external trigger that excluded queue processing. For 34 days, newsletters sat in the queue unsent. Image thumbnails were never generated for new content.
Editors blamed the CDN for broken images. The marketing team wondered why newsletter open rates dropped to zero. Nobody checked the queue.
When a Drupal queue is not processing, the evidence is in the logs. Items added but never consumed. Cron runs without queue worker execution. The pattern is clear - if you’re looking.
Logystera doesn’t guess. It derives truth from logs.
drush queue-list shows all registered queues and current item counts. drush queue-run <queue_name> processes a specific queue. For runtime inspection: SELECT name, COUNT(*) FROM queue GROUP BY name; against the database directly.
Most commonly: an exception in the worker callback that doesn't get caught, leaving the item leased but never released. Drupal's default lease duration is 30 seconds; a worker that never finishes within that window will release the item back to the queue, often to immediately fail again — a poison-message loop.
Yes, but cautiously. Drupal's database queue uses row locking to prevent the same item being processed twice; you can run multiple drush queue-run processes in parallel. For real concurrency at scale, switch the queue backend to Redis or RabbitMQ via contrib modules.
Depends on what the queue does. A queue handling user-visible work (email sending, search indexing) should alert within minutes of stalling. A queue handling background analytics can wait an hour. The right threshold is "what's the cost of this work being delayed?"
Connect your site. Logystera starts monitoring within minutes.
Logystera