How do you analyze observability and infrastructure data in Metabase?
Observability and infrastructure tools hold the operational record of how reliably your systems run: errors, incidents, alerts, deploys, utilization, and cost. In Metabase, bring summaries of those signals into a SQL database and model adjacent layers for incidents, error rollups, service health rollups, and resource snapshots. Those layers support dashboards for MTTA/MTTR, alert noise, availability, SLO compliance, release quality, utilization, and spend — next to the business data the rest of the company already reports on.
TL;DR — Never sync the raw telemetry firehose into a BI warehouse. Sync incidents, error groups, hourly/daily rollups, deploys, inventory snapshots, and cost allocations. MCP is useful for live exploration; durable reliability reporting needs database-backed syncs and history.
Which tools does this cover?
- Sentry — error groups (issues), event rollups, releases, projects
- PagerDuty — incidents, incident log entries, services, escalation policies
- Grafana — alert rules and instances, dashboards, annotations, datasources
- Datadog — monitor and SLO rollups, monitors, incidents, SLOs
- Prometheus — metric rollups, alerts, recording rules, scrape targets
- Cloudflare — zone analytics rollups, firewall events, Workers invocations, DNS analytics
- Amazon ECS — services and tasks, clusters, deployments, Container Insights metrics
- Amazon EKS — clusters and workloads, nodegroups, pods, Container Insights metrics
- Kubernetes — workloads and pods, nodes, namespaces, events
- Google Kubernetes Engine — clusters and workloads, node pools, cluster operations, utilization metrics
- Vercel — deployments, builds, checks, projects
- Honeycomb — query result aggregates, datasets, SLOs, triggers
- Elasticsearch — log and event rollups, indices, index stats, aggregation results
- Kibana — cases, alerting rules, rule executions, dashboards
- Axiom — event rollups, datasets, monitors, APL query results
- Raygun — error groups, error instances, deployments, RUM sessions
For the delivery side of the same story, cross-link the shared model to GitHub and GitLab — deploys and incidents together power the DORA metrics.
What is the shared observability data model?
| Concept | Common terms | Used for |
|---|---|---|
| Incident | Incident, case, outage, page | Incident count, MTTA, MTTR |
| Alert | Alert, monitor event, trigger, notification | Alert volume and noise rate |
| Error group | Issue, error group, crash group, signature | Error inflow, impact, resolution |
| Service health rollup | Availability, error rate, latency percentiles per window | Availability, SLO compliance |
| Deployment | Deploy, release, rollout, build | Deployment frequency, change failure rate |
| Resource snapshot | Workload, service, node, cluster state per day | Utilization, capacity, headroom |
| Cost allocation | Spend by service, namespace, cluster, zone | Cost trends and unit economics |
| Service | Service, application, project, zone, dataset | The join key for everything above |
How do you connect observability tools to Metabase?
- MCP + CLI route — pull a scoped, summarized export through an MCP server, save CSV, and load it with
mb upload csvfor fast exploration. - Pipeline route — sync rollups, incidents, and metadata into a database or warehouse with a connector or API pipeline, then build reliable dashboards.
- Cross-source route — join reliability data to deploys, issues, support tickets, and revenue to explain outcomes, not just outages.
What can you analyze across these tools?
- Incident count — qualifying incidents per period, by severity and service
- Mean time to acknowledge — created to first acknowledge, as a median
- MTTR — failure start to service restored, as a median
- Error rate — error events over total requests or sessions
- Alert noise rate — alerts that never became incidents
- Service availability — successful requests or minutes over total
- 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
Which dashboards should you build?
- Incident response — incident volume, MTTA, MTTR, and on-call load
- Alert quality — alert volume, conversion to incidents, and the noisiest monitors
- Service availability — availability, error rates, and latency by service
- SLO tracking — error budgets, burn rates, and compliance by service
- Release quality — deploys, regressions, and error spikes by release
- Infrastructure cost — utilization vs. requests and spend by service
- Software delivery — the DORA view, joined from deploys and incidents
Common mistakes
Syncing raw telemetry into the warehouse.→ Metrics, logs, and traces belong in the observability stack. The warehouse gets rollups, incidents, and metadata.
Reporting MTTA/MTTR and latency as averages.→ Duration data is heavily right-skewed — report medians and p90/p95/p99.
Averaging availability across services.→ Report each service against its own target; a fleet-wide average hides the one service that's on fire.
Counting alerts as incidents.→ Separate the two and track the noise rate explicitly, or volume dashboards will reward noisy monitors.
Mixing environments in headline numbers.→ Keep production separate from staging; make environment an explicit, filterable column.
Related
Analytics
Integrations
FAQ
What is observability and infrastructure analytics?
Observability and infrastructure analytics is reporting built on the operational record of your systems — errors, incidents, alerts, deploys, utilization, and cost — synced as summaries into a SQL database and analyzed in Metabase. Instead of live triage, it answers longitudinal questions: are we getting more reliable, which services drive incident load, and what does capacity cost? See the observability analytics overview for the full build, and MTTR and SLO compliance for the core metrics.
Does Metabase connect natively to Sentry, PagerDuty, or Datadog?
No — Metabase reads SQL databases and warehouses, not SaaS APIs. Sync each tool's rollups and metadata into a database first with a connector or API pipeline, then point Metabase at that database. For a quick first pass, pull a summarized export and load it with the Metabase CLI (
mb upload csv). Each tool guide — Sentry, PagerDuty, Datadog — documents both routes.Should Metabase replace Grafana or Datadog dashboards?
No — pair them. Operator dashboards in Grafana or Datadog are built for real-time triage, and they should keep that job. Metabase adds what they don't do well: governed metric definitions, org-wide sharing without per-seat operator licenses, and joins with business data — reliability next to revenue, incidents next to releases. The observability analytics overview covers how the two layers divide the work.
How much telemetry should I sync?
As little as answers the question. Hourly or daily rollups per service and environment, incident and alert records, deploys, daily inventory snapshots, and cost allocations cover almost every reliability dashboard — from incident response to infrastructure cost. Never sync the raw metrics, logs, and traces firehose: storage costs explode, queries crawl, and the observability stack already stores those signals better. See service availability for a rollup grain that works.
Can I compute DORA metrics from these tools?
Deploys from your delivery stack plus incidents from tools like PagerDuty give you three of the four keys: deployment frequency, change failure rate, and MTTR. Lead time for changes additionally needs commit timestamps from GitHub or GitLab joined to the deploy that shipped them. See the DORA metrics overview for the data model and performance bands.
Which tools does the observability and infrastructure category cover?
Sixteen tools across four groups: error monitoring (Sentry, Raygun), incident management (PagerDuty), telemetry and logs (Grafana, Datadog, Prometheus, Honeycomb, Elasticsearch, Kibana, Axiom, Cloudflare), and infrastructure (Kubernetes, Amazon ECS and EKS, GKE, Vercel). All of them map onto the same shared model — incidents, error rollups, service health rollups, and resource snapshots — so the dashboards work regardless of which tools you run.
Which dashboards should you build first from observability data?
Start with incident response — incident volume, MTTA, MTTR, and on-call load — because it needs only an incidents table. Add service availability and alert quality once rollups and alert records land, then SLO tracking when explicit targets are published. Release quality and infrastructure cost round out the set as deploy and spend data arrive.