z4j vs. RQ Dashboard

RQ Dashboard Alternative: z4j vs. RQ Dashboard for Python RQ Monitoring

Name: z4j (vs. RQ Dashboard)
Author: z4j

The simple web view for RQ.

Scope: RQ only
Positioning: Lightweight viewer with basic requeue
License: MIT, open source

RQ Dashboard upstream project

what RQ Dashboard does well

Credit where it's due

Zero setup beyond RQ itself - one pip install and a Flask app

Clean, unpretentious UI focused on RQ's primitives

Good enough for small projects that only use RQ

Supports requeue of failed jobs and queue emptying

why teams switch

Reasons to choose z4j over RQ Dashboard

Persistent history beyond Redis TTL

RQ keeps job records in Redis with a TTL. RQ Dashboard only sees what is still in Redis. z4j stores task records in its database, so retained failures remain searchable after the corresponding Redis record expires.

Real bulk actions

RQ Dashboard requeues failed jobs one at a time. z4j has bulk retry with filters (queue, task name, time window, error class) so cleaning up a backlog is one click instead of clicking through pages.

Multi-tenant project scoping with RBAC

RQ Dashboard shows everything on the connected Redis. z4j has per-project scoping with Admin / Operator / Viewer roles, so you can run one z4j for the whole company without leaking queues across teams.

Schedule management

RQ does not include scheduling. Most teams add rq-scheduler separately and end up running it without a dashboard. z4j's z4j-rqscheduler adapter exposes the scheduler in the same UI as the queue.

Tamper-evident audit log

Every privileged action and config change in z4j is HMAC-chained, so the answer to who requeued the failed payment job at 2am is a query rather than a Slack archaeology session.

One dashboard for RQ and everything else

If your stack already has Celery or Dramatiq alongside RQ, or you add them later, z4j shows them in one UI and audit surface. Controls remain capability-aware, so each adapter exposes only the actions it can execute safely.

Notifications across email, Slack, Telegram, webhook

RQ Dashboard does not push alerts. z4j has per-subscription notifications with cooldown, mute, and SSRF-hardened webhook delivery, so on-call gets paged when a job fails or a worker drops off. Queue depth is exported as a Prometheus gauge for your existing alerting to threshold.

Secret redaction is on by default

RQ Dashboard renders raw job arguments. z4j scrubs values that match credential patterns (password, token, secret, api_key, authorization) before they hit the dashboard or audit log.

capability matrix

z4j vs. RQ Dashboard, feature by feature

Capability	RQ Dashboard	z4j
Engine coverage	RQ only	Celery, RQ, Dramatiq, Huey, arq, taskiq
Persistent history	Only what RQ keeps in Redis (TTL-bound)	Database-backed retained task history
Retry / cancel actions	Requeue failed only	Retry, cancel, bulk-retry, requeue-DLQ
Multi-queue across projects	All queues on one Redis	Per-project scoping with RBAC
Schedule management	Not included (needs rq-scheduler separately)	Integrated via z4j-rqscheduler adapter
RBAC / multi-user	Basic-auth or none	Admin / Operator / Viewer
Audit log	None	HMAC-chained, tamper-evident
Historical trends	None	Success, failure, runtime over time
Visual DAG / workflow graph	None	Tidy-tree SVG layout
Secret redaction	Raw args visible	Recursive scrubber + per-task overrides
Real-time updates	Poll-based refresh	Session-authenticated dashboard WebSocket

migration guide

Cut over from RQ Dashboard in a week (or a weekend)

1

Run both side-by-side

Both tools read from Redis. There is no conflict running them in parallel. Leave RQ Dashboard up while you validate z4j.
2

Install z4j-rq alongside your worker

The RQ adapter instruments job lifecycle without monkey-patching. Your existing workers keep running unchanged.
3

Point at the same Redis

z4j picks up the same queues, jobs, and workers RQ Dashboard shows. You gain persistent history from the moment z4j starts recording.
4

Switch off RQ Dashboard once z4j covers your workflow

Keep the docker-compose entry for emergency fallback. Most teams never re-enable it.

frequently asked

z4j vs. RQ Dashboard: FAQ

Is z4j a drop-in replacement for RQ Dashboard?

z4j observes the same Redis that RQ Dashboard reads from, plus the worker process via the z4j-rq adapter. You can run both side by side during the cut-over and turn RQ Dashboard off when you are ready. There is no data migration step.

Does z4j work with rq-scheduler?

Yes. The z4j-rqscheduler adapter detects scheduled jobs and exposes them in the dashboard alongside the live queue. RQ Dashboard does not include scheduling, so this is a strict upgrade if you were running rq-scheduler separately.

How is z4j licensed?

Split licensing. z4j (server, dashboard, API) is AGPL-3.0-or-later. The adapters that ship inside your worker process are Apache 2.0, so importing z4j-rq into a commercial project does not change anything about your application's license. RQ Dashboard is MIT.

Can I self-host z4j?

Yes. Self-hosting is the only deployment model. There is no SaaS option. Three install paths: pip plus SQLite for evaluation, Docker plus SQLite for small teams, Docker plus Postgres for production.

Does z4j support engines other than RQ?

Yes. Celery, Dramatiq, Huey, arq, and taskiq all feed the unified dashboard and audit surface. Task controls are capability-aware: retry, cancel, bulk, and queue controls appear only where the connected adapter can execute them safely.

What is the performance overhead compared to RQ Dashboard?

RQ Dashboard polls Redis when you load a page. z4j runs an agent in the worker and persists structured events in its database. Their overhead depends on event volume, Redis and database sizing, retention, and dashboard use, so benchmark the workload and topology you plan to operate.

Can I keep using RQ Dashboard for some queues and z4j for others?

Both tools read the same Redis without conflict, so technically yes. Most teams find that running one dashboard is simpler than maintaining two. The honest answer is that if z4j covers your workflow, retiring RQ Dashboard is the lower-maintenance choice.

honest trade-offs

Where we don't win

RQ Dashboard is a much smaller tool than z4j. If you only use RQ and never need audit trails, bulk actions, or multi-project scoping, it is simpler to operate.

z4j's value grows with scale. A single developer on a single queue may not need it.

other comparisons