Queue Operations
Perform queue-level control actions including pause, resume, status-based purge, clean, delete, and obliterate.
Route Scope
Queue detail route:
/$orgSlug/c/$connectionId/queues/$queueName
This page combines queue summary, jobs table, and scheduled-job tab.
Available Queue Controls
Pause/Resume Queue
POST /api/c/:connectionId/queues/:queueName/pausePOST /api/c/:connectionId/queues/:queueName/resume
Pause prevents workers from picking up new jobs; jobs already active continue processing. Use it during downstream outages or maintenance, and resume after the underlying issue is resolved.
Clean Queue by Status
POST /api/c/:connectionId/queues/:queueName/clean- Requires
status; optionalgracePeriodin milliseconds (default0) andlimit(default1000).
Supported clean statuses are completed, failed, delayed, paused, waiting, active,
and prioritized (mapped internally to BullMQ equivalents).
Purge Queue Jobs (Guarded + Multi-Status)
POST /api/c/:connectionId/queues/:queueName/purge- Requires:
confirmName(must exactly match queue name)statuses(one or more specific statuses, or["all"])
Purge removes jobs in the selected states. It excludes waiting-children and does not remove schedulers.
Operational behavior:
- users can select any status combination (
waiting,active,delayed,completed,failed,paused,prioritized) - users can choose all supported statuses via
statuses: ["all"] - confirmation input only authorizes purge when exact queue name is entered
Response includes:
statusesPurgedtotalRemovedremovedByStatusremovedJobIdsSample(sample only)
Optional keepMostRecent preserves the newest N jobs across the selected statuses (default 0,
maximum 1000000). Locked jobs may remain or cause a conflict, depending on the removal path.
A purge is not atomic: a 409 can occur after some jobs have already been removed.
Purge Flow in the UI
- Open queue detail settings menu.
- Choose Purge Jobs.
- Select one or more statuses, or All jobs.
- Type exact queue name to enable the destructive action.
- Submit purge and verify updated queue counts.
Obliterate Queue
POST /api/c/:connectionId/queues/:queueName/obliterate
Forcefully removes queue data and its discovery index entry. Unlike the guarded delete endpoint,
this endpoint does not require confirmName or check job counts. Stop producers and workers
before using it; a running application can recreate the queue.
Delete Queue (Guarded)
DELETE /api/c/:connectionId/queues/:queueName- Requires
confirmNamethat must match queue name - Refuses deletion while waiting, active, delayed, failed, paused, or prioritized jobs remain.
- Completed jobs do not block deletion; deletion removes their data too.
- The pre-flight check does not count
waiting-children; inspect dependent jobs separately.
Use pre-flight check route:
GET /api/c/:connectionId/queues/:queueName/can-delete
Safe Deletion Procedure
- Stop producers, remove schedulers that would create new jobs, and stop workers after active jobs finish.
- Purge or clean the supported states, then inspect and handle
waiting-childrenseparately. - Confirm queue is deletable via
can-delete. - Delete with exact queue name confirmation.