Metric · Observability

What is error rate, and how do you measure it in Metabase?

Error rate is the share of failed events — errors over total requests, sessions, or users, per window. It's the metric that turns raw error volume into something comparable across services and releases. Measure it in Metabase from rollups synced from Sentry, Prometheus, Datadog, or Cloudflare.

TL;DRerrors ÷ total per service per window, from pre-aggregated rollups. The denominator is the whole game: errors per what? Pick requests, sessions, or users once and label every chart with it.

What error rate measures

It measures failure density, normalized for traffic. Raw error counts rise with growth even when nothing got worse; error rate separates "more users" from "more broken." Trended by service it feeds availability and SLO reporting; segmented by release it becomes the core of release-quality analysis.

What data does it need?

  • A rollup table with both numerator and denominator per window: error_count(or total - successful) and total_requests / sessions.
  • service, environment, and optionally release_id for segmentation.
  • Source: Prometheus query_range exports, Sentry event rollups plus session counts, Datadog timeseries, or edge analytics like Cloudflare's.

SQL patterns

Error rate by service by weekPostgreSQL
SELECT
  service_name,
  date_trunc('week', window_start) AS week,
  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;
Errors per session by releasePostgreSQL
SELECT
  r.version AS release,
  SUM(e.event_count) AS error_events,
  ROUND(
    1.0 * SUM(e.event_count) / NULLIF(MAX(r.sessions), 0), 4
  ) AS errors_per_session
FROM error_rollups e
JOIN releases r ON r.id = e.release_id
WHERE e.environment = 'production'
GROUP BY r.version
ORDER BY MIN(r.released_at) DESC
LIMIT 15;

Pitfalls

Trending error volume without a denominator.→ Traffic growth masquerades as reliability regression. Always divide by requests, sessions, or users — or caveat the card loudly.
Mixing error severities.→ A handled 404 and an unhandled exception aren't the same event. Filter to the classes that map to user pain, and keep the filter in the model.
Averaging rates across services.→ Small services drown in the fleet average. Report per service, and aggregate by summing numerators and denominators — never by averaging percentages.
Computing rates from sampled events.→ Error trackers sample under load. Use the tool's aggregate counts (which correct for sampling), not a count of stored raw events.

Where this metric applies

Metrics

Dashboards

FAQ

Errors per request, per session, or per user?
Per request for backend services; per session or per user for client apps — that's what crash-free rates are. What matters is consistency: pick one denominator per surface and label it on every card. Sentry supplies session counts for crash-free math, while Prometheus counters give you request-based rates. Keep the two on separate charts rather than blending denominators in one availability view.
How is error rate different from availability?
They are complements when defined on the same events: availability = 1 − error rate for the qualifying error class. Availability is the headline number reported against a target — it feeds SLO compliance and error budgets — while error rate is the diagnostic view you segment by service, release, and error class to find out what actually broke. Same rollup table, two different jobs.
What's an acceptable error rate?
Whatever your SLO says. A payments API and a prefetch endpoint deserve different budgets, so set the target per service tier and measure SLO compliance rather than chasing a universal number. As a sanity check, watch the trend and the release-over-release delta on a release quality dashboard — a rate that doubled after a deploy matters more than any absolute threshold.
How do you calculate error rate?
Divide failed events by total events per window: errors ÷ total_requests (or sessions, or users). In SQL, sum both columns from a rollup table and divide — SUM(total_requests − successful_requests) / NULLIF(SUM(total_requests), 0) — and never average pre-computed percentages, which weights quiet hours the same as busy ones. Compute it from pre-aggregated counts synced from Sentry or Prometheus, because raw stored events are often sampled under load.
How do you track error rate in Metabase?
Sync rollups that carry both numerator and denominator — from Sentry or Cloudflare, for example — into a SQL database keyed by service, environment, and window. Chart errors ÷ total per service per week, add a release-segmented view for regressions, and pin both to the service availability and release quality dashboards.