NGINX One Observability

Overview

I explored a calmer, more legible way to monitor NGINX Open Source and NGINX Plus instances in NGINX One. The work turns the observability journey from observe to diagnose to resolve into a connected data experience.

Complex infrastructure data needed a clearer story

The existing NGINX Plus dashboard placed connections, upstreams, caches, SSL data, and system metrics in dense tables with little hierarchy. I set out to help administrators, DevOps engineers, and SREs recognize health, investigate anomalies, and reach relevant next steps without turning the interface into another wall of telemetry.

01 — Starting point

Read the current state before redrawing it

I began with the existing NGINX Plus experience, where useful signals competed in dense tables and small text. Health, traffic, utilization, and configuration details carried nearly equal visual weight, making it difficult to see what deserved attention first.

Instead of treating this as a chart-style problem, I framed the journey as observe → diagnose → resolve: establish system status, follow a signal into context, then connect the investigation to a relevant resource or action.

Design decision: I chose hierarchy—not more telemetry—as the first design intervention.

02 — Mental model

Map metrics to the questions engineers ask

I worked with product and engineering partners to map relationships among metrics, components, data flow, and navigation. That shared mental model clarified which signals belonged at the instance overview and which needed a deeper analytical view.

I prioritized CVEs, certificates, traffic, utilization, and changes over time because engineers need patterns and correlations, not a stream of isolated real-time numbers. The result gave the team a common basis for scope and information hierarchy.

Design decision: I organized the experience around actionable trends and connected metric groups.

03 — Exploration

Test how much detail the overview can hold

I compared status-led, clean-card, and condensed dashboard directions to find a useful level of density. The studies let me evaluate how cards, sparklines, and numeric summaries could signal change without asking people to parse every value.

The emerging data-explorer direction kept a modular overview as the entry point while leaving room for contextual expansion. It balanced the breadth expected of an observability tool with a visual rhythm that could scale across NGINX Open Source and NGINX Plus.

Design decision: I selected a card-led overview with trend cues and progressive drill-in over an all-in-one map.

04 — Design direction

Compose a linked path from overview to detail

I brought the preferred direction into a dashboard structure of health, utilization, and traffic cards, using sparklines and whitespace to support scanning. Consistent grouping and semantic color create a dependable way to move from overall condition toward a specific metric.

For diagnosis, I paired a combined metrics view with detailed category views. Engineers can compare timelines for possible correlations, then inspect distributions and linked rows for a focused metric without losing the context established by the overview.

Design decision: I used shared visual scales and linked views so comparison and detail feel like one system.

A foundation for the next validation cycle

This design exploration establishes a coherent observability direction for future research, validation, and system integration; it is not a released product or a claim of measured product impact.

• A clearer path from health overview to metric-level investigation.
• Reusable card, chart, and comparison patterns for data-intensive views.
• A shared design direction for product, engineering, and design conversations.

What I learned

I learned that clarity in observability comes from showing relationships and change over time, not from displaying every available number. Next, I would ground the direction in customer research, large-scale visualization validation, and design-system integration.