Database Monitor

Monitor database latency, connections, replication, storage, query health, and failover readiness across environments. This example brings Overview and Queries together so engineering teams can find the next task without losing context.

It includes representative records such as orders-primary and identity-primary. Use the screenshot to study the layout, then adapt its components and product states to your own design system.

Database Monitor
Use this template in Figr

Template facts

Screen

Analytics

Primary action

Open database

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 database while keeping p95 latency, connections and exceptions visible. The interface should show what changed and who should act next.

Key elements

  • Main workspace: Overview gives users an obvious place to start.
  • Supporting view: Queries keeps the related context close.
  • Primary action: Open database stays visible when people need it.
  • First signal: P95 latency shows a useful value (42ms).
  • Second signal: Connections gives additional context (684).
  • Sample record: orders-primary.
  • Next record: identity-primary.

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

Overview → Queries → Open database → Review outcome

Patterns used

Analytics, Overview, Queries, 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 overview and queries. People need to distinguish orders-primary from identity-primary. Keep p95 latency 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 database”. Make error recovery as clear as the happy path.

Related screen examples to explore next: Cloud Cost Explorer, Queue Monitor, Infrastructure Overview.

Start from this in Figr

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

Open Figr