Queue Monitor

Track queue depth, throughput, retries, consumer lag, dead letters, and backlog risk across async workloads. This example brings Queues and Consumers together so engineering teams can find the next task without losing context.

It includes representative records such as billing-events and email-jobs. Use the screenshot to study the layout, then adapt its components and product states to your own design system.

Queue Monitor
Use this template in Figr

Template facts

Screen

Analytics

Primary action

Open queue

Pattern

Analytics

State

Default, loading, empty, error, permission, success

Design system

Configurable product UI theme

What this screen helps users do

Engineering and security teams need to open queue while keeping queue depth, throughput and exceptions visible. The interface should show what changed and who should act next.

Key elements

  • Main workspace: Queues gives users an obvious place to start.
  • Supporting view: Consumers keeps the related context close.
  • Primary action: Open queue stays visible when people need it.
  • First signal: Queue depth shows a useful value (18.4k).
  • Second signal: Throughput gives additional context (2.8k/min).
  • Sample record: billing-events.
  • Next record: email-jobs.

States worth designing

  • No results for the selected range: say what changed, protect progress, and offer a clear next step.
  • Refreshing with old values visible: say what changed, protect progress, and offer a clear next step.
  • Metric source unavailable: say what changed, protect progress, and offer a clear next step.
  • Filter changed the interpretation: say what changed, protect progress, and offer a clear next step.
  • Export preparing: say what changed, protect progress, and offer a clear next step.
  • Restricted data hidden: say what changed, protect progress, and offer a clear next step.

Where this screen sits in the flow

Queues → Consumers → Open queue → Review outcome

Patterns used

Analytics, Queues, Consumers, contextual actions, error recovery

Why these choices work

Keep the time range and metric definition visible. Let people see which segment or filter produced the result, then explain missing or delayed data.

Pay attention to queues and consumers. People need to distinguish billing-events from email-jobs. Keep queue depth visible, especially when a record changes owner or status.

Before this screen reaches handoff, verify keyboard focus, empty and permission states, and what happens after someone chooses “Open queue”. Make error recovery as clear as the happy path.

Related screen examples to explore next: Database Monitor, Job Scheduler, Cloud Cost Explorer.

Start from this in Figr

Design a queue monitor screen inside our existing product. Use our current components, tokens and content language. Include Queues and Consumers views, credible records like billing-events, and a clear “Open queue” action. Use our product permissions and show loading, empty, error and success states. Keep the output editable in Figma.

Open Figr