Redis Insight and BullMQ dashboards: when to use each

Start with the question you need to answer

“Which keys consume memory?” is a database question. “Why has this customer’s export not completed?” is a job question. Starting at the right level saves time: the first needs storage evidence, while the second needs queue identity, job state, attempts, and application context.

Redis Insight documents a key browser, database analysis, command tools, a profiler, and Slow Log. Those capabilities are useful even when the database serves several applications. Its documented core feature set does not include a native BullMQ retry or scheduler workflow. Visualization plugins and custom commands should be evaluated separately.

A queue dashboard should be assessed on the corresponding job workflow: locate an ID, inspect failure evidence, identify dependencies or scheduling, and carry out a supported recovery. A graph of Redis memory cannot by itself tell you whether a particular business operation succeeded.

Treat Redis keys as implementation state

A BullMQ job participates in queue state maintained by the library. Editing a hash or removing a key in a general Redis GUI is not equivalent to asking BullMQ to retry, remove, or move that job through its supported API. Keep operational mutations at the queue API layer unless you are deliberately performing an expert repair with a tested procedure.

For diagnosis, narrow your inspection to the relevant connection and prefix. Redis SCAN is incremental and can return duplicate entries; a changing keyspace is not a transactionally consistent inventory. Avoid turning one scan result into a definitive claim about every queue or job.

Preserve the distinction between “not found in this observation” and “does not exist.” Wrong database selection, a custom prefix, restricted access, and concurrent cleanup are different explanations that need different next steps.

Example: retained history is consuming Redis memory

Suppose memory grows while completed work continues normally. Use database analysis to identify the large key families (it analyzes up to 10,000 keys and extrapolates beyond that), then inspect the application’s job-retention policy. If the evidence points to retained completed or failed jobs, change retention deliberately rather than deleting matching keys ad hoc.

BullMQ supports bounded retention using age and count. The example is a policy illustration, not a universal recommendation: keep completed jobs for up to one day and 10,000 entries, and failed jobs for up to seven days and 50,000 entries. Choose limits from incident response needs and observed job sizes.

Automatic removal is lazy: it runs only when another job finishes in the same state. Queue defaultJobOptions apply to jobs added after the change, while jobs already in Redis keep the options they were added with, so a new policy does not promise immediate cleanup of historical data. Also review job-ID deduplication behavior before shortening retention: removing a prior job changes whether that retained identifier can prevent a future addition.

import { Queue } from 'bullmq'

const queue = new Queue('exports', {
  connection: { host: '127.0.0.1', port: 6379 },
  defaultJobOptions: {
    removeOnComplete: { age: 24 * 60 * 60, count: 10_000 },
    removeOnFail: { age: 7 * 24 * 60 * 60, count: 50_000 },
  },
})

Example: the queue grows but Redis looks healthy

Normal memory and a quiet Slow Log do not establish healthy processing. The queue may be intentionally paused, limited by policy, missing workers, or waiting on a dependency outside Redis. Shift from the database view to queue state, worker visibility, completion history, and representative job errors.

Check the observation window carefully. A flat completion chart with no configured history is different from a verified interval with zero completions. Durabull’s native metrics documentation explains the worker settings needed for history; its Redis health views separately report freshness and coverage.

Once evidence identifies the cause, make the smallest appropriate change and observe the result. If a downstream API is failing, inspect that service’s telemetry before adding consumers or retrying many jobs. The two interfaces should help narrow the incident, not compete to be the only tool used.

Build a runbook that connects both views

Record the environment, database, prefix, queue, job ID, and timestamps in the incident note. Link the queue evidence to database metrics from the same interval. Assign an owner for application recovery and another for datastore changes when those responsibilities differ.

Use Redis Insight when detailed Redis investigation is needed, a BullMQ dashboard when the task is queue operation, and application telemetry for the business side effect. You do not need every tool for every incident. You need a repeatable way to move between layers without losing context or treating one healthy component as proof of end-to-end success.

Common questions

Sources & review

Written by Durabull. Reviewed 20 October 2026 against the references below and Durabull’s implementation. Pricing examples are documented models, not measured benchmarks or vendor quotes.

Suggest a correction if a feature, price, or documented behavior has changed.

Compare the options

• Durabull vsRedis InsightOfficial Redis GUI. Excellent for keys and slowlog. Not a BullMQ job dashboard.
• Durabull vsDatadogRedis metrics plus first-party BullMQ tracing and Data Streams Monitoring. Pair with a queue console to inspect and retry jobs.
• Durabull vsBull BoardMIT dashboard with embedded adapters and a standalone Redis-discovery CLI.