#Production checklist

Quick gate before exposing the dashboard to real traffic.

#Auth

The dashboard has no built-in auth. Add one. See Add basic auth. Serving a token-based SPA? See auto-login from a token-based frontend.

#CSRF

Destructive actions (retry, clean, pause, drain, obliterate) are state-changing requests. Behind a browser session, they're CSRF-reachable. See CSRF protection.

#Read-only where possible

If the audience is "everyone with a login", most of them don't need obliterate. Mark queues read-only and enable retries only on the queues that need them.

#Multi-tenancy

Running a shared dashboard across tenants? Add a visibility guard. Don't rely on "nobody will guess the queue name", since the name is in the URL.

#Polling interval

Default is 5 seconds. If the dashboard has many open tabs, every tab polls every queue. Cap it with pollingInterval.forceInterval or leave the picker on so users can dial it down. See Polling interval.

#Redis access

The dashboard connects directly to Redis via your queue instances. If Redis is reachable from the dashboard process, the dashboard can do anything Redis permits. Treat dashboard access as Redis access.

#Environment badge

Production and staging sharing a browser? Set environment.label = 'production' with a red color on the production instance. Small thing, saves a real outage.

serverAdapter.setUIConfig({
  environment: { label: 'production', color: '#cc0000' },
});

#Version pinning

The dashboard talks to your Bull / BullMQ instances. Mismatched versions across workers and the dashboard have bitten people (see issues #1074, #1088, #1097). Pin the same BullMQ across both.

BullMQ v5 and v6 are both supported, and the adapter detects which one it has. Upgrading workers and the dashboard separately is still the thing to avoid, since the two majors store a paused queue's jobs differently. See supported versions.

#Response checking

options.validateResponses checks every response body against the schema its route declares and answers 500 when one does not match. Leave it off in production, which is the default: the check walks the whole body on every poll, and the same mismatch already fails the build. Turn it on while developing a custom server adapter, a historyProvider, or a handlerHooks.after hook that reshapes bodies, where a mismatch would otherwise reach the dashboard as a rendering bug.

createBullBoard({
  queues,
  serverAdapter,
  options: { validateResponses: process.env.NODE_ENV !== 'production' },
});

#Logs

Workers that call job.log() will have their lines visible in the dashboard under each job's Logs tab. If you're wondering "what did this job do before it failed", that's the answer. See Job logs and flows.

#Alerting

The dashboard won't page you. It only shows state while a tab is open. Wire failure alerts to BullMQ's own events, not to bull-board. See Alerting on failed jobs.