State-gated job actions
Add, inspect, promote, retry, requeue and cancel jobs. Every action is gated by the job's actual current state, so the UI never offers something the server would reject. Job Inspector →
Skip to contentThe only queue dashboard that also
MIT licenseZero-dependency npm packageStandalone binaries for 5 platformsMulti-arch Docker imageLimits documented honestly → 1 2 3 4 5 6 7 8 9 10 11 12
bunqueue dashboard
The only queue dashboard that also
runs the server
A free, open source web UI that fully drives a bunqueue server (a fast, Redis-free, Bun-native background-job queue): queues, jobs, dead-letter queue, cron, webhooks, workers and live activity, plus start / stop / restart of the server process itself. Built for Bun developers and AI-agent builders who want to operate their queue, not just watch it. It talks only to bunqueue's public HTTP API and a tiny loopback control agent.
Open the live demoQuick startGitHub
Overview
Features
Everything an operator needs to run a bunqueue server from the browser, from state-gated job actions right through to the process lifecycle. Every card below is a shipped page you can open in the demo right now.
Live activity stream
A Server-Sent-Events feed with automatic reconnect shows jobs flowing in real time. It is built on fetch, so it works with bearer-token auth, unlike EventSource. Live logs →
DLQ triage
A fleet-wide dead-letter dashboard plus a single-queue triage surface: failure reasons, per-attempt history, retry one / retry all / purge, CSV export. DLQ Control →
Cron manager
Schedule by cron expression or interval-in-ms with a next-runs preview, then list and delete existing schedules. Cron →
Webhooks
Register endpoints with event scoping and an optional HMAC secret; watch success/failure counts, toggle, delete. Webhooks →
Server lifecycle
The one thing HTTP can't do, namely starting, stopping and restarting the bunqueue process, is delegated to a small loopback-bound agent with an Origin + Host allowlist, locked CORS and an optional bearer token. Server Control →
SQLite inspector
Browse tables, schema and indexes, page through rows, run SELECT-only queries with EXPLAIN and CSV/JSON export, all over a read-only connection, capped at 500 rows. Database →
Metrics & throughput
Rolling live throughput charts, error-rate gauge, per-operation latency percentiles (push / pull / ack × p50 / p95 / p99). Metrics →
Client-side alerts
Threshold rules on queue depth, failures, error rate and latency, evaluated in the browser, with in-app toasts and desktop notifications. Alerts →
Benchmark
Push and drain load runs against any queue, in count or duration mode, with a live chart and run history. Benchmark →
Flow DAG viewer
Parent / children / depends-on relationships drawn as a graph, laid out client-side with no graph library. Flows →
AI Copilot experimental
An in-app assistant that drives the same API through tools. Bring your own key, and requests go straight from your browser to your provider. Copilot →
Tour
See it in action
A real control surface, not a read-only viewer, so every screen in this tour is a live page you can drive in the demo.
Surface
Everything you can drive
Queuespause · resume · rate-limit · concurrency · drain · obliterateJobsadd · inspect · promote · retry · requeue · cancelDLQreasons · per-row retry · retry-all · purgeCronexpressions or intervals · next-runs previewWebhooksevent scoping · HMAC secrets · delivery statsWorkershealth · last seen · unregisterServerstart · stop · restart · live process logsDatabaseread-only SQLite tables · schema · queries
Process
Up and running in four steps
The priority is simplicity: one command serves the dashboard, proxies the API and runs the control agent. No clone, no build.
Step 1
Run it
One process serves the dashboard on http://127.0.0.1:8080, proxies /api/* to your bunqueue server and runs the control agent.
bash
bunx bunqueue-dashboardStep 2
Point it at your server
Set the server URL and bearer token from the Settings page (tokens stay in memory, never written to localStorage) or via BUNQUEUE_URL / VITE_BUNQUEUE_URL.
Step 3
…or let it run the server for you
From Control ▸ Server the agent starts, stops and restarts the bunqueue process, with an editable launch config and a colour-coded live log tail.
Step 4
Drive it
Explore jobs, triage the DLQ, schedule cron, watch live activity. Destructive actions are confirmed and name their target; everything else is one click.
Get started
How to install
Four ways to run it, pick the one that fits. All of them serve the same app.
bash
bunx bunqueue-dashboard
# → http://127.0.0.1:8080, serves the SPA plus the /api proxy and control agent, zero dependenciesbash
# Download the binary for your platform from the GitHub Releases page,
# then make it executable and run it, nothing else to install:
chmod +x bunqueue-dashboard-v*-darwin-arm64
./bunqueue-dashboard-v*-darwin-arm64
# → http://localhost:8080bash
docker run --rm -p 8080:80 ghcr.io/egeominotti/bunqueue-dashboard:edge
# → http://localhost:8080, set the server URL from the Settings pagebash
bun install
bun start
# agent (http://127.0.0.1:6800) + dashboard (http://localhost:5273) togetherFAQ
Frequent questions
What is this, and why not just curl the API?
A complete operator surface over bunqueue's HTTP API: scheduling, triage, limits, live activity and process lifecycle in one UI, with every job action gated by the job's real state, instead of hand-rolled curl scripts and guesswork about which action a job will accept.
Does it touch my server's code or data?
No. It never imports or modifies bunqueue source. It speaks only to the public HTTP API. The SQLite inspector opens its own read-only connection and accepts SELECT-style statements only, so it cannot write even if asked to.
Is the control agent safe to run?
The agent can spawn processes, so it's locked down: bound to 127.0.0.1, an Origin allowlist with CORS never set to *, a Host-header allowlist against DNS rebinding, and an optional AGENT_TOKEN on state-changing requests. The full threat model is in the agent docs.
Where do my tokens and secrets live?
In memory only. Server tokens, agent tokens, S3 keys and webhook targets are deliberately excluded from localStorage, so re-enter them per session or supply them via environment variables.
Can I try it without a bunqueue server?
Yes, the live demo runs the real app against fixture data in your browser. Every page works, no backend required.
How do I deploy it?
Four ways: the zero-dependency npm package (bunx bunqueue-dashboard), a standalone binary for linux/macOS/windows, the multi-arch Docker image, or from source. The binary embeds the SPA, the API proxy and the agent in one file.
What doesn't it do?
Alerts are evaluated in the browser while a tab is open, so it's not away-from-desk paging. S3 backup is configured by the server's environment, not from the UI. Every other verified gap is listed, with file references, on the known issues page.
Is my data sent anywhere?
No telemetry. The only optional egress is the AI Copilot: if you enable it, requests go directly from your browser to the LLM provider you configure, using your own key.