A server dashboard can be green while the application feels broken. The server may return a successful response, but the page might take too long to become useful, a button may appear to do nothing, or a save may fail after the interface has already displayed a success message. Operational monitoring and user experience are connected, but they are not the same measurement.
Useful observability starts with a question: can people complete the task they came to do, and how reliably? That question leads to a small set of measurements across the browser, application, and infrastructure. It does not require collecting a detailed history of every visitor.
Measure outcomes, not just activity
Page views, request counts, and CPU usage describe activity. They do not automatically describe success. A form can receive thousands of requests while most submissions fail validation. A search endpoint can be fast while returning irrelevant results. A map can load its first tiles while routing remains unavailable.
Choose a few important user journeys and define what success means for each one. For a document upload, success might mean that the file passed validation and is available to the user—not merely that the upload request returned a response. For a search tool, success might include a response within a reasonable time and a result state that the interface can display. The exact outcome depends on the product, so it should be written down rather than inferred from a generic dashboard.
Use latency distributions instead of one average
An average response time can hide a painful tail. If most requests are quick but a small group takes several seconds, the mean may look acceptable while some users wait. Percentiles help reveal that difference. The median describes a typical observation; a high percentile helps show the slower experiences that still affect a meaningful portion of requests.
Measure important operations separately. A page navigation, a search request, a file upload, and a background synchronisation task have different expectations. Combining them into one latency number makes it difficult to decide what needs attention. Record enough context to distinguish the operation and outcome, but avoid placing private document contents, passwords, or unnecessary personal identifiers in telemetry.
Observe the browser as well as the server
For web interfaces, browser-side measurements can show problems that server timing cannot. The Web Vitals project describes metrics related to loading, responsiveness, and visual stability. These measurements help identify whether a page becomes useful, responds to interaction, and avoids unexpected layout movement.
Do not treat a single performance score as the whole experience. A page can meet a timing target while still having confusing controls, inaccessible errors, or a workflow that loses user input. Combine performance measurements with task-level checks and direct usability feedback. The goal is to find the cause of friction, not to chase a number because it appears in a report.
Connect metrics, logs, and traces carefully
Metrics show patterns over time. Logs explain individual events. Traces show how a request moves through multiple services. These signals complement one another. A rise in failed saves may appear in a metric; a structured log can explain the validation or storage error; a trace can show whether the delay came from the application or a downstream dependency.
OpenTelemetry provides common concepts and instrumentation libraries for collecting telemetry across systems. A small project does not need to adopt every component at once. It can begin with a few well-defined metrics and structured error events, then add traces when there are multiple services or asynchronous steps that are difficult to understand from logs alone.
Define a service objective people can understand
A service-level objective is a target for a meaningful reliability or performance measure over a stated period. It might describe the proportion of successful operations or the share of requests that complete within a chosen latency. The target should reflect the importance of the feature and the experience the team can realistically support.
Do not choose a target simply because another service uses it. A public search tool, an internal export operation, and a background map download do not have the same cost or user expectation. Start by measuring the current experience, identify what would be unacceptable, and set a target that guides engineering decisions.
An error budget makes the trade-off visible: if the service has already used most of its allowed failures for the period, the team should be more cautious about risky changes. That is a decision aid, not a licence to ignore every failure until a number is exhausted. Serious data loss or security incidents require action regardless of a dashboard percentage.
Keep observability privacy-conscious
Telemetry can become a second database of user behaviour if nobody defines limits. Collect the smallest set of fields needed to diagnose a problem. Prefer aggregated counts and timings where they are sufficient. Avoid recording raw form values, file names, document contents, authentication tokens, full URLs containing private query parameters, or persistent identifiers that are not necessary for the purpose.
Set retention periods and access controls. Make sure error messages do not include secrets. If a diagnostic event needs a request identifier to connect logs, use a short-lived or carefully scoped identifier rather than turning it into a cross-site tracking key. Observability should help maintain the service without quietly expanding the amount of personal information the service stores.
A small starting dashboard
- Successful and failed outcomes for the most important user journeys.
- Median and high-percentile latency for those operations.
- Browser loading, interaction, and layout-stability measurements where relevant.
- Dependency failures and queue or storage pressure.
- Recent deployments and configuration changes alongside the metrics.
- One documented path from an alert to the logs or trace that can explain it.
For the infrastructure side, our guide to backpressure in small services explains why bounded queues and careful retry policies matter under load. The OpenTelemetry signals overview describes metrics, logs, and traces, while web.dev’s Web Vitals guide explains the user-facing performance measurements.
The best dashboard is not the one with the most graphs. It is the one that helps a team notice a real user problem, narrow down its cause, and decide what to do next. Start with the journeys that matter, measure them honestly, and keep the data collection proportionate to the job.
What do you want to say about this?