Two of these panels are the same series. Which two?

For platform & SRE teams

Two of these panels are the same series. Which two?

methodGET_status200vsrequest_rate_total r = 0.99987

Found on a live Prometheus instance. Not similar — the same numbers, on two separate panels, alerting separately.

Two hundred tiles. Four pages for one incident. And nobody has deleted a panel in two years, because nobody can prove which ones are safe to remove.

This reads a dashboard export and tells you how many genuinely distinct things it measures, which panels are one measurement shown twice, and which are safe to archive — with the evidence for each.

See it run on real infra data Or drop your own export

Runs in your browser. Your file is read in this tab and never uploaded — open the network panel and check.

What it checks

Every check runs on every file — and the ones that did not fire get printed too, along with the one we have not built yet. You can tell what a tool actually covers by what it admits it doesn't.

Everything spiked, so everything correlated During an incident every metric moves at once, and raw correlation calls them all related. Both the raw and the change-over-time view are computed and shown, so a shared timeline doesn't get read as a shared cause.

The same number on two tiles A rate and its complement. A count and its percentage. Bytes and megabytes. Pairs matching at r ≥ 0.999 are one measurement displayed twice — and you get told which one to keep.

Totals that are just their parts A request total that is exactly the per-status counters added up. Archive the total, keep the parts — never the reverse, because every member of that family looks individually redundant and dropping them all loses the lot.

Worst-of and max() panels A cluster-health tile taking the max across nodes is fully determined by its inputs, yet naive scoring ranks it your most important signal — because which node is worst keeps changing.

Related, but your correlation check says no Two metrics sitting at r ≈ 0.03 that are strongly dependent anyway: a threshold effect, a saturation curve, a queue that only backs up past 80%. Measured against a shuffled null so the estimator's own noise isn't reported as a finding.

When normalising changes the answer Divide by request rate and two panels suddenly look identical. That's either a real duplicate you'd been missing, or an artefact you just created. You get both readings and how to tell them apart — it will not guess for you.

Run an audit

Export any dashboard to CSV. Columns are metrics, rows are timestamps. Nothing is uploaded.

How to use this

01Drop your export Grafana, Datadog, Prometheus — anything that produces a CSV. First row is metric names. Read in this tab, never sent anywhere.

02Pick a lens Optional. Renames the findings for your domain. It cannot change a number, only what the finding is called.

03Start with what fired Each finding names the metrics involved. Archive candidates come with the evidence for why they're safe.

Drop a CSV here
or click to choose · nothing leaves this machine

No export to hand? This one is 17 metrics × 400 days, built from four known drivers with two exact duplicates and one nonlinear pair hidden in it. The audit comes back with 4.3 — it was never told the answer.

"Safe to archive" is a claim, so it has to be checked

The real reason nobody prunes a dashboard is that whoever deletes the wrong panel owns the next incident review. So nothing here archives anything on its own.

→

It can prove one thing That a metric carries no variation the others don't already carry. That is arithmetic, and it is checkable.

→

It cannot see the rest That the same metric is the sole condition on a paging rule, an SLO error budget, or a compliance export. None of that is in a CSV of values, and the tool says so rather than guessing.

→

So it hands you a worksheet Every candidate with the evidence for why it is listed, and columns only you can fill: referenced by monitors, SLOs, runbooks, last queried. Completing that is the safety check.

One guard worth knowing about: when a total and its parts are all on the board, every one of them looks individually redundant. An unguarded tool offers you the whole family. This one protects the parts and offers only the total.

We wrote down what we expected to find. Then we checked.

A tool only ever pointed at data whose structure nobody knows can never be caught being wrong. So the predictions go on disk before the data is pulled, and get scored afterwards — misses included. Several of the most useful results were our own bugs.

Dashboard	Shape	Result	What it found
NYC COVID daily counts	53 × 455	5.1 signals	Raw view says 1.6 — during a pandemic every metric rides the same wave
ACT air quality	12 × 1,094	4.7 signals	NO₂ and CO at r = 0.03 but 177× their Gaussian-implied dependence
Prometheus infrastructure	11 × 437	5.6 signals	status=200 and request_rate identical at r = 0.99987
FDIC bank call reports	39 × 1,915	2.5 → 14.8	Raw totals said 2.5. Normalising per-unit revealed 14.8 — size was hiding everything

Worth knowing what that discipline catches. Adding the totals check exposed a bug we had been shipping: when a total and its parts are all on the board, every one of them looks individually redundant — so the tool offered all six members of one family for deletion at once. Take that advice and you lose the whole thing. It is guarded now, and the episode is written up in the public failure log rather than quietly patched.

About the engine & author

One question: how many distinct things is this dashboard actually measuring? A forty-panel board driven by four underlying system states gives its owner the feeling of forty-fold coverage and the reality of four. That gap is where duplicate alerts come from, and it is what this measures.

It was built by someone who got tired of dashboards nobody trusted and panels nobody would delete, and who wanted the argument settled with evidence instead of opinion.

How we know it works

Before each dataset is pulled, what we expect to find gets written down and committed. A tool only ever pointed at data whose structure nobody knows can never be caught being wrong — so we make it possible to catch. Every dataset in REAL_DASHBOARDS.md carries its predictions and the score, misses included. Several of the most valuable results were misses, because they turned out to be bugs in this tool rather than bad guesses about the data.

Structural invariants

It never guesses how to read your data. Raw, change-over-time, and per-unit views are all computed. Which one the headline reports is something you declare — because a tool that guesses wrong hands you a confident wrong answer, and that is the exact failure this exists to catch.
The engine is blind to meaning. It emits mathematical states. Domain lenses rename them in this interface and cannot reach the mathematics.
Two readings, never a verdict. When normalising makes two panels look identical, that is either a duplicate you had missed or an artefact the normalising created. Both turned up in the same dataset looking exactly alike. So you get both readings and the test that separates them — you know your system, the arithmetic doesn't.
Checks that did not fire are still shown. Anyone can print a correlation matrix and a big number. The difference is the list of ways this one was stopped from lying to you — including the check we have not built, which is on the page rather than left off it.

What it does not do

Stated here rather than buried. It does not detect a metric plotted against its own rolling average — two designs were built and withdrawn on evidence, and it renders as an unchecked circle rather than a claim. It does not know what your metrics mean, so a statistically redundant column may be worth keeping for contractual or diagnostic reasons. Equal-occupancy binning degrades on integer counts with few distinct values. And nothing here is causal: two metrics in a cluster may share a driver, or one may cause the other, or both may be measuring an instrument rather than the world.

Where the name comes from

Redd Munro is not a person. Both halves are Scots, and both describe the tool.

Redd means to clear out and set in order — you redd up a room before you can see what is in it. A Munro is a Scottish peak over 3,000 feet, and the genuinely hard part of Sir Hugh Munro's 1891 tables was never the measuring. It was deciding which summits count as separate mountains and which are just subsidiary tops of the same one. People have argued about it ever since.

That is this tool in one sentence. Not every summit is a separate mountain, and not every panel is a separate signal.

Author

Built by Shaun Cooper, independent systems theorist. The engine grew out of a research programme that spent most of its effort trying to break its own measurements, and catalogued the distinct ways a comparison like this can produce a publishable-looking wrong answer.

Runs entirely in your browser via Pyodide. No account, no upload, no telemetry — which would be an awkward thing for this particular tool to collect.