Custom Queues

Plenty of Craft projects run more than one queue — a dedicated import queue, a channel for heavy media processing, or a separate runner kept off the default queue so long jobs don’t block everything else. Queuebert surfaces all of them in a single bar.

How Detection Works

When Queuebert builds its summary, it asks Craft for the primary queue plus every application component that implements craft\queue\QueueInterface, and aggregates their job info. Custom queue runners are conventionally registered as application components in config/app.php, so they’re picked up automatically — there’s nothing to register with Queuebert itself.

Example: A Second Database-Backed Queue

Here’s a second queue on its own channel, registered as an app component:

return [
    'components' => [
        'importQueue' => [
            'class' => \craft\queue\Queue::class,
            'db' => 'db',
            'channel' => 'import',
            'tableName' => '{{%queue}}',
            'mutex' => \craft\mutex\Mutex::class,
        ],
    ],
];

With that in place, jobs pushed to importQueue appear in the bar’s totals alongside the default queue — no extra configuration required.

What Counts

Any queue component implementing QueueInterface contributes its running, waiting, and failed counts to the bar. The Inspect Limit setting bounds how many jobs Queuebert inspects per queue when building the detailed summary, keeping the poll fast even when a queue is very deep.

Read-Only, Always

Queuebert reports on your custom queues but never drives them. It doesn’t start runners, retry failures, or move jobs between channels — it only reflects the state Craft already tracks.