Who is connected, and how it is going.
Which workers are registered, what the queue has processed, and the time-windowed counters behind a dashboard.
Workers and metrics
Section titled “Workers and metrics”const workers = await queue.getWorkers(); // Active workers on this queueconst count = await queue.getWorkersCount();
const completedMetrics = await queue.getMetrics('completed', 0, 100);const failedMetrics = await queue.getMetrics('failed', 0, 100);
const removed = await queue.trimEvents(1000); // Keep the newest 1,000 eventsconst workers = await queue.getWorkers(); // Active workers on this queueconst count = await queue.getWorkersCount();
const stats = await queue.getStats(); // Server-wide statsconst metrics = await queue.getMetrics(); // Server-wide metricsworkers = queue.get_workers() # Active workers on this queuecount = queue.get_workers_count()
stats = queue.get_stats() # Server-wide statsmetrics = queue.get_metrics() # Server-wide metrics$workers = $queue->getWorkers(); // Active workers on this queue
$stats = $queue->getStats(); // Server-wide statsworkers, _ := queue.GetWorkers() // Active workers on this queue
stats, _ := queue.GetStats() // Server-wide statsThe Rust SDK does not expose queue monitoring helpers yet. Read the broker’s Prometheus endpoint instead:
curl --fail http://localhost:6790/metricsThe Elixir SDK does not expose queue monitoring helpers yet. Read the broker’s Prometheus endpoint with the standard Erlang HTTP client instead:
:inets.start(){:ok, {{_, 200, _}, _headers, body}} = :httpc.request(~c"http://localhost:6790/metrics")Worker and stats helpers are not yet exposed in Rust and Elixir; scrape the server’s HTTP /metrics endpoint instead. trimEvents() and windowed getMetrics(state, start, end) exist in the Bun bunqueue package only.
Metric windows
Section titled “Metric windows”getMetrics(type, start = 0, end = -1) is queue-scoped in both embedded and
TCP mode. It returns:
interface QueueMetrics { meta: { count: number; // Cumulative terminal jobs for this queue and type prevTS: number; // Timestamp of the most recent terminal job prevCount: number; // Count in its one-minute bucket }; data: number[]; // One-minute buckets, newest first count: number; // Available buckets before pagination}start and end are inclusive bucket indexes, not timestamps. Index 0 is
the newest minute and end: -1 means through the oldest retained minute. Empty
minutes between observed buckets are returned as zero. Unlike BullMQ’s Redis
collector, bunqueue includes the current partial minute immediately, so one
finished job produces a visible data point without waiting for the minute to
close. The broker retains at most 20,160 points (two weeks) per queue and state;
meta.count remains cumulative when older points age out.
trimEvents(maxLength) operates on the separate lifecycle-event journal. It
returns the number of deleted entries, affects only this queue, and is
idempotent: calling it again with the same length returns 0. The journal is
SQLite-persistent, automatically bounded to 10,000 entries per queue, and is
deleted together with queue metrics by obliterateAsync().
Where to go next
Section titled “Where to go next”| Queue API | Create a queue in embedded or TCP mode |
| Adding Jobs | add, addBulk, priorities, delays, durability |
| Deduplication and Idempotent Job Adds | Idempotent adds, dedup keys, custom job ids |
| Querying Jobs | Fetch jobs, states, counts and results |
| Queue Control and Maintenance | Pause, drain, obliterate, clean and repair |
| Progress, Job Logs and Dependencies | Progress, per-job logs and dependencies |
| Queue Rate Limiting and Global Concurrency | Rate limits and global concurrency caps |
| Job Schedulers from the Queue | Named repeatable schedules from the queue |
| DLQ Operations from the Queue Object | Failed-job operations from the Queue object |
| Namespaces, Auto-Batching and Store-and-Forward | Namespaces, auto-batching, store-and-forward |
| JobOptions Reference | Every JobOptions field, with defaults |