A dashboard nobody revisits keeps tracking metrics the business already moved past

What it is

The metrics chosen when a dashboard was created reflect the business priorities at that time, but the business changes: product lines are retired, definitions are rewritten, data sources are decommissioned, KPIs are swapped. The dashboard itself has no way of knowing—the renderer faithfully draws whatever the configuration says, even when that definition no longer means anything. Over time, some metrics become "zombie metrics": they still display numbers, but no one can explain what business behavior those numbers correspond to, or their computation references fields that no longer exist. Zombie metrics occupy attention while providing zero information—and worse, because the numbers look normal, they can mask the fact that the data pipeline behind them is actually broken.

Why it happens

Metric decay is gradual and invisible: when an upstream field is renamed, dependent queries may silently return null (the chart shows a gap) or return a cached old value (the number still moves but no longer reflects reality). The rendering layer cannot distinguish "valid data whose business meaning has changed" from "broken data pipeline"—both may look identical on screen. The accumulation of decay stems from missing maintenance incentives: the person who built the dashboard had motivation to make it run, but no one has a KPI for "keep the dashboard correct." Without an owner, decay accelerates; with an owner who later leaves the team, it enters the same unmaintained state. This resembles technical debt in code but is harder to spot: code that fails to compile errors immediately, whereas a decayed dashboard raises no error—it just keeps displaying data that no longer means anything.

Where it stops holding

Not every "still displayed but rarely viewed" metric is decayed: low-frequency metrics required for compliance (e.g., regulatory reporting) may be rarely viewed but must stay. The criterion for decay is not view frequency but "whether a clear mapping still exists between the data and the current business entity"—if a metric's definition references a retired product line, it is decayed even if someone still checks it out of habit. Another boundary is automation: some data systems provide schema-change notifications that can let a dashboard auto-flag affected metrics when upstream fields are renamed, but this depends on upstream maturity and is not universally available.

Applying it

• Assign an owner to every dashboard and update ownership on personnel changes (part of the offboarding checklist).
• Run a quarterly metric audit: list each metric's definition, upstream source, and recent view frequency; flag metrics whose definitions reference defunct entities or that have had zero views in 90 days for retirement.
• On data-source schema changes, automatically detect affected dashboard metrics and notify the owner.
• Verification: pick 5 metrics from the dashboard and ask current team members what business behavior each one measures; any metric that cannot be clearly explained is a decay candidate.

Related

• Same group: U7.10.1 Customization increases personal fit but weakens the team's shared reference · U7.10.2 Personal configurations must be distinguished from the official version and resettable · U7.10.4 Metric definition changes must notify everyone reusing the dashboard · U7.10.5 Dashboards no one views should be retired rather than kept
• Nearby: U7.05.5 The comparison period's statistical scope must match the current period's · U7.10.5 Dashboards no one views should be retired rather than kept
• Search terms: metric decay · dashboard maintenance · stale metrics