RQ

Package: z4j-rq - RQ 1.15+.

Install

pip install z4j-rq

What it captures

RQ doesn’t expose signals in the Celery sense - z4j hooks Queue.enqueue_call and patches Worker.work to emit lifecycle events.

Hook	z4j event
Queue.enqueue_call	task_sent
Worker.perform_job (start)	task_started
job success	task_succeeded
job failure	task_failed
job requeue	task_retry

Actions

Verb	How
retry	Queue.enqueue with original function + args, mark old as retried_as
cancel	send_stop_job_command(connection, job_id) if running; job.cancel() if queued
purge_queue	queue.empty()
bulk_retry	loop, capped at 10k

Multiple queues

RQ uses many queues per app. The agent discovers all queues on first connection via Queue.all(connection). Each queue appears separately in the dashboard with its own counts.

RQ-worker-pool

rq-worker-pool works fine - each worker in the pool registers as its own agent. Use agent_name with $PID to distinguish.

Caveats

• Failed queue - RQ moves failures to a special failed registry. z4j reads this on first connect and emits synthetic task_failed events for visibility.
• Scheduler read-only (v1.0) - schedule CRUD for rq-scheduler is on the v1.1 roadmap.
• Dependencies - job.depends_on chains show in the dashboard as “waiting on”.

Config

No explicit config; reads Redis connection from RQ itself.

Multiple Redis targets:

Z4J = {
    ...,
    "rq": {"connection": "myapp.redis.rq_conn"},
}

See scheduler: rq-scheduler.