Dashboards / Data information / Ratio and rate

Ratio and rate

A raw count misleads; the viewer needs it normalized by a denominator they understand.

Updated September 9, 2026

Problem

Four hundred errors. The viewer can’t act on that, because four hundred out of four hundred million is a good day and four hundred out of six hundred is an outage, and the count alone doesn’t say which.

Solution

Divide by something the viewer already understands. Errors per request, revenue per customer, cost per gigabyte, requests per second. The choice of denominator is the entire pattern, and it is the part dashboards habitually hide.

Two failure modes account for most of the damage.

The invisible denominator. A tile reading 99.9% is unreadable without knowing 99.9% of what, over what window. The same figure over a minute and over a quarter describe different systems. Percentages computed over small denominators are worse than useless: one failure out of three is 33%, which will sit next to a genuine 33% computed over millions and look identical.

The smoothing you didn’t ask for. Rates are computed, not measured, and the computation makes choices. Prometheus rate() automatically adjusts for counter resets from target restarts, and extrapolates to the ends of the range to cover missed scrapes, so the value on the panel is deliberately slightly synthetic. That’s the correct behavior and it means the number is smoother than reality. Prometheus is also explicit that applying rate() to a gauge produces a nonsensical result and runs the query without complaining, which is a class of dashboard bug that never announces itself.

The fix on the design side is small and almost never done: put the denominator on the tile. “0.04% of 2.1M requests, last 5m” is one line longer and answerable.

Use when

The raw count changes with volume and the viewer cares about the underlying condition rather than the traffic. Error rates, conversion rates, utilization, unit economics.

Don’t use when

The count itself is the thing someone acts on. Open incidents, people on call, orders waiting to ship. Nobody dispatches against a percentage. Also don’t normalize when the denominator is small or unstable enough that the ratio swings more than the numerator does.

Trade-offs

A ratio deletes scale. The viewer loses the ability to tell a rounding error from an outage, which is why a rate should almost always be shown next to its count rather than instead of it. Rates additionally hide burstiness: an even trickle and a hard spike inside the same window produce the same per-second average. And ratios are the easiest metric to construct dishonestly without lying, by choosing a denominator that flatters, which is a thing dashboards do to themselves as often as to anyone else.

Checklist

What is the denominator, and is it on the screen?
Over what window, and is it the same window as everything beside it?
How large does the denominator get at the quiet end of the day, and does the ratio stay meaningful there?
Is the raw count shown alongside, so the viewer can size the problem?
Is this a rate over a counter, and does the query handle resets?
Could this function be running against a gauge, where it would return nonsense silently?
Does the smoothing hide bursts the viewer would care about?
Percent, per-mille, or per-unit, and does the unit match how the team talks?
If this ratio feeds an SLO, is the SLO’s window the same as the panel’s?
What does the tile show when the denominator is zero?

Compare

Grafana treats normalization as a query concern and formatting as a panel concern, so a ratio’s correctness lives in PromQL the viewer never sees while the panel confidently formats whatever comes back as a percentage. Netdata leans on per-second rates as the default unit of everything, which makes bursts visible where a per-minute average would have flattened them. Honeycomb prefers to keep the raw events and derive the ratio at query time, so the denominator is something you chose in the query rather than something baked into a metric name months ago. Sentry normalizes by session and by release, which turns “how many errors” into “what fraction of sessions were bad”, the form product teams can actually argue about. Cloudflare Radar puts the denominator where nobody can miss it, printing both sides as text above the bar so “Bot 57.9%, Human 42.1%” reads without the chart at all. That suits an audience which will take one figure and leave, and it means the ratio cannot be misread by anyone who skips the encoding.

KPI tile is the container, and inherits every denominator problem above. Percentile summary is the other way to avoid being fooled by an average. Explain this metric is the escape hatch for the denominator question when it won’t fit on the tile. Metric targets is where a ratio becomes an SLO and the window suddenly matters a great deal more.

Wireframe — the pattern's anatomy, not any one product's version of it

Implementation

99.9% of ten requests is one failure. The denominator is what makes a rate readable, and it is the first thing dropped when a tile gets tight.

Tokens: --foreground--muted--muted-foreground--border--chart-1

LightDarkCode

Error rate

0.04%

842 of 2,104,338 requests

Last 5 minutes

Rate.tsxThe denominator is a required prop and a low-count rate is marked as unreliable.

/**
 * A rate without its denominator is not a measurement.
 *
 * 99.9% over ten requests and 99.9% over four million are different claims, and
 * only one of them survives a single bad minute. `of` is required, and below a
 * threshold the component says the number is thin rather than letting a viewer
 * read it as precision.
 */
export function Rate({
  numerator,
  of,
  label,
  unit,
  minReliable = 100,
}: {
  numerator: number;
  of: number;
  label: string;
  /** What is being counted: "requests", "sessions". */
  unit?: string;
  minReliable?: number;
}) {
  const pct = of === 0 ? null : (numerator / of) * 100;
  const thin = of < minReliable;

  return (
    <div>
      <p className="text-xs text-muted-foreground">{label}</p>
      <p className="mt-1 text-2xl font-semibold tabular-nums text-foreground">
        {/* Two decimals at both ends. 99.95% and 0.04% are the rates people
            act on, and one decimal rounds both to a lie. */}
        {pct === null ? "—" : `${pct.toFixed(pct > 99 || pct < 1 ? 2 : 1)}%`}
      </p>
      <p className="text-xs tabular-nums text-muted-foreground">
        {numerator.toLocaleString()} of {of.toLocaleString()}{unit ? ` ${unit}` : ""}
        {thin && <span className="ml-1 text-status-warn">· small sample</span>}
      </p>
    </div>
  );
}

demo.tsxHow it is called: numerator, denominator and what is counted.

import { Rate } from "./Rate";

/** A rate with its denominator in view. Drop `of` below 100 and it says so. */
export default function Demo() {
  return (
    <div className="w-[272px] rounded-lg border bg-card p-5">
      <Rate label="Error rate" numerator={842} of={2_104_338} unit="requests" />
      <p className="mt-4 text-xs text-muted-foreground">Last 5 minutes</p>
    </div>
  );
}