48.3k Log in Get started
Dashboard

What does a service availability dashboard show in Metabase?

A service availability dashboard shows whether each service meets its reliability bar — availability, error rate, and latency, per service, against explicit targets. It's built from hourly or daily rollups synced from tools such as Prometheus, Datadog, Cloudflare, and Elasticsearch.

For: SREs, service owners, and leadership. Grain: one row per service per hour or day — rollups, never raw telemetry.

Which cards belong on a service availability dashboard?

  • Availability by service, trailing 28 days (table)
  • Error rate by service by week (line)
  • Latency p95/p99 by service (line)
  • Services below target right now (number + table)
  • Availability trend for the worst five services (line)
  • Traffic volume by service for context (bar)
  • Incidents overlaid on availability dips (timeline)

What data does the dashboard need?

  • service_health_rollups — per service and environment: window start, total requests, successful requests, and pre-aggregated latency percentiles.
  • services with owner, team, and tier, so targets differ by criticality.
  • Optional incidents to annotate dips with what happened.

How do you build it?

  1. Define success once — status < 500, or probe-based — and apply it in the rollup job, not per chart.
  2. Export hourly or daily aggregates per service from your telemetry stack into a database (see the Prometheus guide for routes).
  3. Pre-aggregate latency percentiles in the source — percentiles can't be re-averaged from rollups later.
  4. Build the per-service table against targets first, then trends and drill-throughs.

Example card SQL

Availability and error rate by service by weekPostgreSQL
SELECT
  service_name,
  date_trunc('week', window_start) AS week,
  ROUND(
    100.0 * SUM(successful_requests) / NULLIF(SUM(total_requests), 0), 3
  ) AS availability_pct,
  ROUND(
    100.0 * SUM(total_requests - successful_requests)
    / NULLIF(SUM(total_requests), 0), 3
  ) AS error_rate_pct
FROM service_health_rollups
WHERE environment = 'production'
GROUP BY 1, 2
ORDER BY 1, 2;

Metrics

Service availabilityError rateSLO compliance

Integrations

Prometheus + MetabaseDatadog + MetabaseCloudflare + MetabaseGrafana + Metabase

Dashboards

SLO trackingIncident responseInfrastructure cost

FAQ

What is a service availability dashboard?
A service availability dashboard reports whether each service meets its reliability bar — availability, error rate, and latency percentiles per service, judged against explicit targets. It differs from a live monitoring screen in Grafana or Datadog: it works on hourly or daily rollups in a database, built for weekly reviews and leadership reporting rather than 3 a.m. triage.
What data sources feed a service availability dashboard?
Aggregates from your telemetry stack: Prometheus recording rules, Datadog metric queries, Cloudflare HTTP analytics, or Elasticsearch log aggregations. Export them as a service_health_rollups table — per service and window: total requests, successful requests, and pre-aggregated latency percentiles — plus a services table with owner and tier. Never sync raw telemetry; the rollup grain is the whole trick.
Why not average availability across all services?
Because a 99.99% service and a 97% service don't average into anything a decision can use — the blend hides exactly the service that needs attention. Report each service's availability against its own tier-appropriate target, and make "services below target" the headline number. If leadership wants one figure, give them that count, or a traffic-weighted view with the per-service table one click away.
Request-based or time-based availability?
Request-based (successful ÷ total requests) reflects user experience and weights busy services naturally — a five-minute outage at peak counts more than one at 4 a.m. Time-based (uptime minutes over total minutes) suits probe-monitored or low-traffic systems where request counts are too small to be meaningful. Pick per service class, label the cards, and keep the definition consistent with your SLO tracking so the two dashboards never disagree.
How is availability different from SLO compliance?
Availability is the measurement; an SLO is the published promise it gets judged against. This dashboard reports the measured numbers — availability and error rate per service. SLO compliance adds targets and error budgets on top, turning 99.2% into "fine" or "breach." Build this dashboard first; once targets are agreed and published, extend the same rollups into an SLO tracking dashboard.