A dashboard nobody has opened in months should be retired, not left consuming compute indefinitely

What it is

The number of dashboards in an organization only grows: every project creates its own, and when the project ends the dashboard stays in the system, continuing to consume compute, appearing in search results, and occasionally being opened by a new colleague who closes it in confusion. These "unviewed" dashboards are not neutral inventory—they are active liabilities: queries still run (costing money), metrics may have decayed yet are still displayed (misleading), and the search list keeps growing (making it harder for new users to find a valid one). A retirement policy is the endpoint of the dashboard lifecycle, just as products have sunsets and code has deprecations—dashboards need an exit path too.

Why it happens

The cost of keeping unused dashboards is so diffusely distributed that no one feels it: each dashboard's query cost is negligible in the overall bill, but organizationally it accumulates into significant resource consumption. The subtler cost is to the information ecosystem: when searching "user retention" returns 12 dashboards, the new user doesn't know which is authoritative—the selection cost transfers to them, along with no basis for judging (which has an owner, which is still updating, which definition is correct). This "choice overload" compounds with metric decay: the easiest-to-find dashboard may not be the most current but the best at keyword stuffing, and new users make judgments on stale data. The resistance to retirement comes from sunk cost ("effort went into creating it") and uncertainty ("what if someone needs it later"), but neither justifies ongoing maintenance—keeping an unviewed dashboard is like paying server costs for a page no one visits.

Where it stops holding

"Unviewed" needs a reasonable time window and an exceptions list: 90 days of zero views is a common retirement candidate standard, but compliance-mandated reports, incident-review dashboards awaiting archiving, and low-frequency but critical quarterly business reviews belong on a keep list rather than auto-retirement. Retirement does not mean deletion: archiving (preserving configuration and historical data without continuing computation) versus hard deletion are different treatments—the former preserves the possibility of future restoration at far lower cost than continued running. Process matters too: advance notice to the owner, a grace period for stakeholders to object, and a restoration entry after retirement all reduce organizational friction.

Applying it

• Build a dashboard inventory recording last-viewed time, owner, and data-source status for each.
• Set a retirement rule: dashboards with zero views in the last 90 days and no compliance-hold reason become retirement candidates; after owner notification, archive if no objection within 14 days.
• Hide retired dashboards from search results or tag them "archived" to prevent new users from using them.
• Verification: count dashboards retired vs created over the past 6 months; if creation consistently exceeds retirement, the inventory is still growing and the policy needs more aggressive enforcement.

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.3 Long-frozen dashboards keep using metrics that are no longer valid · U7.10.4 Metric definition changes must notify everyone reusing the dashboard
• Nearby: U7.10.3 Long-frozen dashboards keep using metrics that are no longer valid · U7.04.4 Too many alerts train users to ignore alerts
• Search terms: dashboard lifecycle · sunset policy · archive vs delete