Okay so I’ve been deep in our Claw dashboards for the last week, trying to figure out why our monitoring bill spiked 30% after our last feature rollout. Turns out, classic cardinality explosion from some new tags we added without thinking about the downstream cost.
I spent about two hours this morning digging into the high-cardinality culprits. The biggest offender was a `user_session_id` tag we were attaching to every single span and log line for “better debugging.” Huge mistake. That one tag was generating thousands of new series. Claw’s pricing model eats that for breakfast and charges you for dinner.
Here’s the query that finally helped me see the damage and start cutting it down. I ran this in Claw’s query explorer to find the most expensive tags by series count:
`metric:requests_total | group_by([service, environment, http_status]) | rate:5m`
The key was removing the dynamic, high-volatility tags (`user_session_id`, `request_id`) from the grouping and keeping only the stable, meaningful dimensions we actually use for alerts and dashboards (`service`, `environment`, `http_status`). We moved those volatile IDs to log messages only, where they’re still searchable but don’t create new metric series.
The result? A 40% reduction in our estimated bill for next month. It feels like a design system cleanup, but for observability—pruning the unnecessary variables that create chaos. Has anyone else found specific tags that silently murder their budget? I’m wondering if `client_ip` or full URLs in metrics are common traps too.