Observability dashboards built on all your telemetry

What are observability dashboards?

Observability dashboards are visual views that combine telemetry into a picture of how a system behaves. A monitoring dashboard typically shows time series charts, single values, tables and status indicators for services, infrastructure or business processes. Dashboards answer recurring questions at a glance: is the checkout service healthy, how full are our clusters, did the last release change latency?

Dashboards are not a replacement for alerts or investigations. Alerts tell you when to look, and investigations explain why something happened. Dashboards provide the shared overview in between: during on-call handovers, release reviews, incident calls and capacity planning.

Why good dashboards matter

Many organizations have hundreds of dashboards, yet during an incident nobody knows which one to open. Dashboards drift out of date, are copied for every environment and only work for the person who built them. Different tools for metrics, logs and traces add another layer of switching.

Good dashboards are few, focused and owned. They follow a consistent structure, use the same naming and labels across services and link directly into deeper analysis. They also need to be accessible to everyone who benefits from them, which is difficult when tools charge per user.

How dashboards work in Obseria

When data arrives, Obseria uses TopoGraph to create prebuilt dashboards for discovered services, Kubernetes clusters, hosts, databases and cloud services. They show the golden signals and resource metrics most teams need first and can be copied and customized.

Custom dashboards support PromQL, OQL and SQL. You can show a PromQL latency percentile next to an OQL panel with error logs and a SQL table that joins telemetry with deployment data:

histogram_quantile(0.95,
  sum by (le, service) (rate(http_server_request_duration_seconds_bucket{service="$service"}[5m])))

Template variables such as service, cluster or environment keep one dashboard usable for many contexts. Every panel offers drill-down: from a spike to the slowest traces, from an error rate to the matching log lines, from a service to its upstream and downstream dependencies.

Dashboards as code

Dashboards are configuration and deserve the same care as application code. In Obseria, every dashboard can be exported and imported as JSON and managed through the API, the CLI or Terraform. Teams keep dashboards in Git, review changes in pull requests and roll out the same dashboard to staging and production. Coding agents can also create or update dashboards through the Obseria MCP server, with changes visible for review.

Dashboards during incidents

During an incident, the most useful dashboard is the one that opens with the right context. Alerts in Obseria link to the dashboard of the affected service with the time range and variables already set, so responders do not have to search. Incident timelines can embed panels, and every chart shows deployment and configuration markers. When the cause is still unclear, a panel can be handed to Obseria Intelligence, which follows the topology from the visible symptom to likely causes and lists the evidence it used. After the incident, the same panels become part of the postmortem, which keeps the analysis reproducible and based on the data responders actually saw.

Sharing and collaboration

Obseria pricing is based on usage, with unlimited users. Developers, SREs, support and management can all open the same dashboards without license discussions. Dashboards are organized in folders, shared with teams or via links and protected by roles and permissions. Annotations mark deployments, incidents and configuration changes so everyone sees the same timeline.

Dashboard best practices

1. Start with a question. Each dashboard should answer a defined question for a defined audience.
2. Use the golden signals. Traffic, errors, latency and saturation form a consistent top row for every service.
3. Show SLOs prominently. Error budget status tells viewers quickly whether action is needed.
4. Prefer variables over copies. One parameterized dashboard is easier to maintain than ten duplicates.
5. Annotate changes. Deployment and incident markers make cause and effect visible.
6. Retire unused dashboards. Review usage regularly and remove what nobody opens.