Dashboards / Data information / Ranked list

Ranked list

The viewer needs to know which few items dominate, not the distribution of all of them.

Updated September 9, 2026

Problem

Something is consuming the budget, or throwing the errors, or taking the time. There are nine thousand candidates and the viewer needs the handful that account for most of it.

Solution

Sort descending, cut at N, show the values. The sort is trivial. The cut is the pattern, and everything interesting is about what happens at the cut line.

Say what’s below it. A top ten with no total is a list of ten things and no sense of whether they’re 90% of the problem or 4% of it. An “other” row, or a share-of-total figure on each line, converts a leaderboard into an answer. Without it the viewer cannot tell a heavy-tailed distribution from a flat one, and those call for completely different responses.

Say what the ranking is over. Top ten endpoints by latency over the last hour is not the top ten at any moment inside that hour. A ranked list computed across a window silently averages away the thing that spiked for ninety seconds and then left, which on an operational dashboard is frequently the thing you were looking for.

Watch the churn. Over a high-cardinality dimension the membership of the top ten changes on every refresh, and a list that reorders itself while someone is reading it is unusable. This is the axis observability tools diverge on: Honeycomb’s whole argument is that high cardinality is where the answers are and the tooling should hold up under it, rather than pre-aggregating the interesting dimensions away before anyone can rank by them.

Use when

The distribution is genuinely skewed and the viewer’s job is triage. Which customers, which endpoints, which queries, which hosts.

Don’t use when

The values are close together. Ten items within a few percent of each other produce a ranking that is noise given an ordering, and readers treat position as meaningful whether or not it is. Show the distribution instead. Also don’t rank when the set is small enough to show entirely.

Trade-offs

Ranking imposes a total order on things that may not have one, and readers over-trust position: first and second read as meaningfully different even when they differ by a rounding error. The cut at N is arbitrary and usually invisible, so an item at position eleven is indistinguishable from one at position nine hundred. Ranked lists also concentrate attention on the head by construction, which is the point, and which means slow accumulating problems in the tail never surface. And on a shared dashboard the list becomes a scoreboard, which changes behavior in ways nobody specified.

Checklist

Why N? Is it ten because ten is the answer or because ten fits?
Is the total, or each item’s share of it, visible?
Is there an “other” row, and does it carry the count of what’s in it?
Is the ranking over the whole window, and would a per-interval ranking say something different?
How stable is the membership between refreshes, and is the list readable while it updates?
Are ties broken deterministically, so the order doesn’t jitter?
Can two adjacent rows be distinguished, or are they within noise?
Can the viewer click through to the item, and do they land somewhere scoped correctly?
What’s the cardinality of this dimension, and does the query hold up at that cardinality?
Does the list say what it’s ranked by, in the units the viewer thinks in?

Compare

Grafana builds this out of a bar gauge or a sorted table, which means the “other” row and the share-of-total are things whoever wrote the query has to remember, and they usually don’t. Honeycomb treats ranking as a step inside the analysis loop rather than a finished panel, so a top-N is somewhere you group by a dimension and then keep going, which suits a high-cardinality field where the interesting item was never in anyone’s top ten. Sentry ranks issues by event count and keeps a sparkline on each row, so the list carries shape as well as order and a spiking issue at position twelve is still visible. Netdata ranks per-node and per-second, so the list turns over fast enough that it reads as a live view rather than a standing. Cloudflare Radar strips the magnitudes out entirely: its top tens are a number, a name and nothing else, with no bar and no share of total. That is the most aggressive answer available to the question this pattern raises, and it holds up because for a reader who came for one fact the rank genuinely is the whole finding.

Data table is this pattern without the cut, and the right answer once the viewer wants to sort by something else. Drill-down is where a rank position should take them. Filter bar is how they narrow the population before ranking it. Stacked composition answers the share-of-total question graphically. Cross-filter is what turns a list item into a scope for the rest of the page.

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

Implementation

A top-N is a table that has given up sorting. The rank is the finding, so the bar is drawn inside the row rather than beside it, and the tail is named instead of being silently dropped.

Tokens: --card--card-foreground--muted-foreground--border--status-warn--chart-1

LightDarkCode

Errors · last 1 hourShare

141%
219%
39%
46%
54%

other · 2,140 endpoints21%

RankedList.tsxTakes the top rows, the total and the cardinality, and computes each share and the other row from them. The window is a required prop.

export type Ranked = { name: string; value: number };

/**
 * Sort descending, cut at N, and account for the cut. The list takes the
 * top rows plus two numbers the query already knows, the total and the
 * cardinality, so it can draw the "other" row every leaderboard omits. Without
 * that row a heavy tail and a flat one look the same.
 */
export function RankedList({ measure, window, top, total, cardinality, noun, onSelect }: {
  /** What the rows are ranked by, in the viewer's units. "Errors". */
  measure: string;
  /** The window the ranking covers. Top five over an hour is not the top
   *  five at any moment in it, so the window is required, not a caption. */
  window: string;
  /** The rows above the cut. Sorted here, ties broken by name so the order
   *  never jitters between refreshes. */
  top: Ranked[];
  /** Sum of the measure across every item, above and below the cut. */
  total: number;
  /** How many items the dimension has. The other row carries the count. */
  cardinality: number;
  /** What an item is called: "endpoints", "tenants", "queries". */
  noun: string;
  onSelect?: (name: string) => void;
}) {
  const rows = [...top].sort((a, b) => b.value - a.value || a.name.localeCompare(b.name));
  const above = rows.reduce((n, r) => n + r.value, 0);
  const other = { value: total - above, count: cardinality - rows.length };
  const pct = (v: number) => `${Math.round((v / total) * 100)}%`;
  // Bars are scaled to the top row, so the lead's size is the first thing read.
  const bar = (v: number) => ({ width: `${(v / rows[0].value) * 70}px` });

  return (
    <div className="w-[340px] rounded-lg border bg-card p-4">
      <div className="flex items-baseline justify-between border-b pb-2 text-[11px] uppercase tracking-wide text-muted-foreground">
        <span>{measure} · {window}</span>
        <span>Share</span>
      </div>
      <ol className="mt-1">
        {rows.map((r, i) => (
          <li key={r.name} className="flex items-center gap-2 py-1.5 text-xs">
            <span className="w-3 tabular-nums text-muted-foreground">{i + 1}</span>
            <button type="button" onClick={() => onSelect?.(r.name)} disabled={!onSelect}
              className="w-24 truncate text-left text-card-foreground enabled:hover:underline" title={`${r.value.toLocaleString("en-GB")} ${measure.toLowerCase()}`}>
              {r.name}
            </button>
            <span className="h-2 rounded-[1px] bg-chart-1" style={bar(r.value)} />
            <span className="ml-auto tabular-nums text-card-foreground">{pct(r.value)}</span>
          </li>
        ))}
      </ol>
      {other.count > 0 && (
        <div className="mt-1 flex items-center gap-2 border-t border-dashed pt-2.5 text-xs text-status-warn">
          <span>other · {other.count.toLocaleString("en-GB")} {noun}</span>
          <span className="h-2 rounded-[1px] bg-status-warn" style={bar(other.value)} />
          <span className="ml-auto tabular-nums">{pct(other.value)}</span>
        </div>
      )}
    </div>
  );
}

demo.tsxHow it is called: five endpoints out of 2,145, ten thousand errors in the hour.

import { RankedList } from "./RankedList";

/**
 * Ten thousand errors in the last hour across 2,145 endpoints. Five of them
 * account for 79%; the other row says what the remaining 2,140 add up to.
 */
export default function Demo() {
  return (
    <RankedList
      measure="Errors"
      window="last 1 hour"
      top={[
        { name: "/api/checkout", value: 4100 },
        { name: "/api/search", value: 1900 },
        { name: "/api/cart", value: 900 },
        { name: "/api/user", value: 600 },
        { name: "/api/feed", value: 400 },
      ]}
      total={10_000}
      cardinality={2145}
      noun="endpoints"
      onSelect={(name) => console.log("open", name)}
    />
  );
}

What it renders. Identical markup in both panes, with only the token values changing.

Copy-paste: this implementation as plain text

Examples

Captures whose hotspots reference this pattern, grouped by product and dated. The dashed boxes are this pattern; hover any box for the note.

Ranked list

Problem

Solution

Use when

Don’t use when

Trade-offs

Checklist

Compare

Implementation

Examples

Cloudflare Radar

Grafana

Plausible Analytics

Tableau Public

Ranked list

Problem

Solution

Use when

Don’t use when

Trade-offs

Checklist

Compare

Related

Implementation

Examples

Cloudflare Radar

Grafana

Plausible Analytics

Tableau Public