Skip to content
CM Box Documentation

Background queues

CM Box moves slow work off the request path onto background queues: when an author uploads a video or an event triggers a webhook, the web application enqueues a job and a separate worker process executes it. This page explains what runs on the queues and how to watch them from the admin dashboard.

How it works

Section titled “How it works”

The queues are BullMQ queues on a dedicated Redis instance (separate from the content store), processed by the cm-box-process service — one of the four containers in a CM Box deployment (see Deployment). If the process service is down, jobs accumulate as waiting and run when it returns.

CM Box runs five queues:

Queue What runs on it Triggered by
Conversions Media renditions and dynamic document (DOCX) conversions Uploading or updating assets that need renditions
Webhooks Outbound webhook deliveries Content events matching an enabled webhook
Auto-Archive Scans for items past their scheduled archive date A recurring schedule (every 15 minutes by default)
Auto-Publish Scans for drafts past their scheduled publish date A recurring schedule (every 15 minutes by default)

Worker parallelism, the queue Redis connection, and the two scan schedules are controlled by environment variables on the process service — BULLMQ_REDIS_HOST, BULLMQ_REDIS_PORT, BULLMQ_CONCURRENT_WORKERS, AUTO_ARCHIVE_CRON, and AUTO_PUBLISH_CRON. See the environment variable reference.

Monitor the queues

Section titled “Monitor the queues”

The queue dashboard requires the admin.queue.view permission (admin.queue.manage for managing jobs — see Security).

In the admin area, open Queue. A dropdown switches the dashboard between the Conversions and Webhooks queues. The dashboard has two panels:

  • Events Log — the queue’s recent event stream, with Type, Time, Job ID, Event, and Response columns. Failed events show in red, successful return values in green.
  • Jobs — an accordion of the queue’s jobs by status, with live counts: Active Jobs, Waiting Jobs, Failed Jobs, and Completed Jobs. Each job card shows the job’s name and ID, its timestamp, a Progress: value, and either a Completed Message: (the job’s result) or a Failed Message: (the failure reason).

Managing jobs

Section titled “Managing jobs”

Hover over a job card and click the trash icon to remove it. You can remove waiting, failed, and completed jobs; active jobs cannot be removed from the dashboard.

There is no retry action: a job that failed stays in Failed Jobs as a record, and you re-run the work by repeating the action that queued it — re-saving the asset for a conversion, or re-triggering the event for a webhook delivery (webhook deliveries are attempted once and never retried automatically; see Webhooks and workflow integration).

Completed and failed jobs on the Conversions, Webhooks, and OCM Sync queues are not pruned automatically — they remain in Redis until removed. If the completed and failed lists grow large, remove jobs from the dashboard, or bulk-remove jobs in one state through the queue REST API:

DELETE /api/queue/<queue-name>/jobs?jobState=<completed|failed>

The scheduled scan queues clean up after themselves (the last 100 completed and 50 failed scans are kept).

Section titled “Related”