Speaking Topic: Observability Debt as Its Own Technical Debt Category
Unused dashboards and unbounded cardinality are technical debt, they just do not show up on the engineering backlog.
Technical debt conversations almost always default to code: shortcuts, missing tests, brittle modules. I argue observability debt deserves its own category, because it compounds the same way and is measured even less often.
Unused dashboards, unbounded metric cardinality, and alert rules nobody has looked at in a year are not neutral. They cost money every month and they actively slow down incident response by burying the signal that matters under noise nobody has pruned.
The fix looks like any other debt repayment: a quarterly audit, a defined threshold for pruning, and ownership assigned to someone who is accountable for the telemetry bill the same way someone is accountable for the engineering backlog.
Key Takeaways
- 01Observability debt compounds the same way code debt does, and is measured far less often.
- 02Unused dashboards and unbounded cardinality are not neutral, they cost money and slow incident response.
- 03Observability debt needs the same quarterly audit discipline as any other technical debt category.
Frequently Asked
How do you audit observability debt specifically?
By reviewing dashboard and alert usage against actual reference logs, and measuring metric cardinality against its real diagnostic value, the same discipline applied to any other debt audit.
From the Q&A
“Why doesn't this get caught in normal engineering reviews?”
Because it lives in observability tooling configuration, not application code, so it falls outside the surfaces most code review processes are built to examine.