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: 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

z4j has bulk retry with filters (task ids, engine, state, queue, task name, a since/until time window, and priority or a text search on the durable path), so cleaning up a backlog retries exactly the failures you mean in one request.

Multi-tenant project scoping with RBAC

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

Schedule management

If you run rq-scheduler, z4j's z4j-rqscheduler adapter exposes those schedules in the same UI as the queue, instead of leaving them without a dashboard.

Tamper-evident audit log

Privileged actions and configuration changes in z4j land on an HMAC-chained log, 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 shows jobs as RQ stores them. z4j redacts arguments named like credentials (password, token, secret, api_key, authorization), including keyword arguments and dict keys inside RQ's job description, plus values shaped like known secrets, before the event leaves the worker, and scrubs again on ingest.

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 (schedulers run separately)	Integrated via z4j-rqscheduler adapter
RBAC / multi-user	Basic-auth or none	Admin / Operator / Auditor / Viewer
Audit log	None	HMAC-chained, tamper-evident
Historical trends	Point-in-time queue and job views	Success, failure, runtime over time
Visual DAG / workflow graph	None	Tidy-tree SVG layout
Secret redaction	Raw args visible	Secret-named arguments and secret-shaped values scrubbed in the worker, again on ingest
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 hooks the worker's job execution to capture the lifecycle. Workers load it with one register_worker_bootstrap() call in a module they import, plus the Z4J_BRAIN_URL, Z4J_TOKEN and Z4J_PROJECT_ID settings.
3

Point at the same Redis

z4j reads queue depth from the same Redis and records jobs and workers as instrumented workers run them. 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, so rq-scheduler gets the same dashboard as the rest of your stack.

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.

Can I self-host z4j?

Yes. Self-hosting is the only deployment model. There is no SaaS option. Three guided install paths: pip plus SQLite for evaluation, Docker plus SQLite for small teams, Docker plus Postgres for production; the sdist also ships a Helm chart, raw Kubernetes manifests and systemd units.

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 and bulk actions run only where the connected adapter advertises them.

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