Infrastructure Overview

Monitor compute, databases, queues, traffic, regions, deploys, and service health across production infrastructure. This example brings Overview and Services together so engineering teams can find the next task without losing context.

It includes representative records such as Compute clusters and Primary databases. Use the screenshot to study the layout, then adapt its components and product states to your own design system.

Infrastructure Overview

Template facts

Screen

Analytics

Primary action

Open service

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 service while keeping services, healthy 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: Services keeps the related context close.
  • Primary action: Open service stays visible when people need it.
  • First signal: Services shows a useful value (148).
  • Second signal: Healthy gives additional context (96%).
  • Sample record: Compute clusters.
  • Next record: Primary databases.

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 → Services → Open service → Review outcome

Patterns used

Analytics, Overview, Services, 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 services. People need to distinguish Compute clusters from Primary databases. Keep services 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 service”. Make error recovery as clear as the happy path.

Related screen examples to explore next: Incident Timeline, Cloud Cost Explorer, Service Catalog.

Start from this in Figr

Design a infrastructure overview screen inside our existing product. Use our current components, tokens and content language. Include Overview and Services views, credible records like Compute clusters, and a clear “Open service” action. Use our product permissions and show loading, empty, error and success states. Keep the output editable in Figma.

Open Figr