What is observability analytics, and how do you build it in Metabase?

Observability analytics turns errors, incidents, alerts, deploys, utilization, and cost signals into shared metrics about how reliably your systems run — and what that reliability costs. In Metabase, build it by syncing summaries of those signals into a SQL database, modeling clean incident, error-rollup, service-health, and resource layers, and shipping dashboards that put reliability next to the business data everyone already trusts.

What does observability analytics measure?

• How often do things break, and how fast do we recover?
• Are alerts signal or noise — and is on-call sustainable?
• Which services miss their availability or SLO targets?
• Does each release make the error picture better or worse?
• Where is capacity over- or under-provisioned?
• What does infrastructure cost per service, team, or tenant?
• How does reliability correlate with delivery pace and revenue?

Which tools feed observability analytics?

What shared data models should you build?

Build clean models on top of raw source tables so each dashboard uses the same definitions.

• incidents — one row per qualifying incident, with created, acknowledged, and resolved timestamps
• alerts — one row per alert or monitor firing, flagged with whether it became an incident
• error_groups and error_rollups — one row per error group, plus daily counts and affected users
• service_health_rollups — hourly or daily availability, error, and latency aggregates per service
• slo_definitions — explicit targets so compliance is measured against something published
• deployments — one row per production deploy, joined to incidents and error spikes
• resource_snapshots — daily workload, node, or service capacity and usage
• cost_allocations — spend by service, namespace, cluster, or zone per day
• services — the join table: stable IDs, owners, teams, and tiers

Which observability metrics matter most?

• Incident count — qualifying incidents per period, segmented by severity and service.
• Mean time to acknowledge (MTTA) — created to first acknowledge, as a median.
• MTTR — failure start to service restored; the DORA stability metric.
• Error rate — error events over total requests or sessions per window.
• Alert noise rate — alerts that never became incidents over all alerts.
• Service availability — successful requests or minutes over total, per service.
• SLO compliance — actual reliability against explicit targets and error budgets.
• Resource utilization — used capacity over requested or provisioned capacity.
• Deployment frequency and change failure rate — the DORA throughput and stability pair.

How do you connect tools to Metabase?

1. MCP + CLI — use MCP for a scoped, summarized live export, thenmb upload csv for quick analysis.
2. Warehouse-backed pipeline — sync rollups, incidents, deploys, snapshots, and costs with APIs or connectors for durable dashboards.
3. Modeled layer — map each source into the shared incident, error, service-health, and resource models while preserving source-specific extension tables.

Which dashboards should you build first?

• Incident response— incident volume, MTTA, MTTR, and on-call load.
• Alert quality — alert volume, conversion, and the noisiest monitors.
• Service availability — availability, error rate, and latency by service.
• SLO tracking — error budgets, burn rates, and compliance.
• Release quality— deploys, regressions, and error spikes by release.
• Infrastructure cost — utilization vs. requests and spend by service.
• Software delivery— the DORA view across deploys and incidents.

Common mistakes

Related

Integrations

FAQ