Our bill jumped 300% after a traffic spike. Is Claw's pricing model broken?

Okay, I need to vent and get some collective wisdom. We’ve just been through a classic migration scenario, but the destination wasn't a new database—it was an observability bill from the underworld.

We migrated our primary logging and metrics from a legacy on-prem stack to Claw Observability about six months ago. The pitch was solid: predictable pricing based on "analyzed volume" with clear tiers. We did our due diligence, modeled our average daily volume, added a 50% buffer for spikes, and the pilot month was within 10% of the estimate. All good.

Then last week, a marketing campaign went viral (the good problem to have). Our traffic spiked 5x for about 48 hours. We expected a billing bump, but the preliminary data from Claw shows our bill is tracking for a **300% increase** over our baseline. Not 5x, but 3x the *cost* on 5x the *traffic*. The math feels broken.

My migration-brain kicked in and I started digging into the raw usage data and their pricing docs. I think I've found the "gotchas," and they're classic for anyone who's dealt with usage-based SaaS migrations. Here’s my breakdown:

**The Suspects:**

1. **Cardinality Explosion:** Our request volume spike meant new user IDs, new session IDs, new combination of tags. Suddenly, we're not just sending more data points, we're creating entirely new time series. Claw's pricing, I discovered buried in an appendix, applies a multiplier for "high-cardinality dimensions." Our cost per GB wasn't static; it effectively went up as our data got more unique.

2. **The "Analyzed" vs "Ingested" Bait-and-Switch:** Our contract is for "Analyzed Volume." During normal ops, we sample our debug logs at 10%. The spike triggered a new error condition, and our alerting rules (which we migrated as-is) changed the sampling rate to 100% for error logs. Claw counted all of it as "analyzed" because it passed through their parsing pipeline. We were, in effect, penalized for having detailed error traces.

3. **Tiered Pricing Trap:** We were comfortably in the 100-500 GB/day tier. The spike pushed us into the 500-2000 GB/day tier, but the volume discount at that new tier is minimal. The marginal cost per GB above 500GB/day is nearly the same as the cost below it. So the pricing curve isn't a smooth function; it's more like a steep staircase.

Here's a snippet of the naive calculation vs. the reality we think is happening:

```python
# What we modeled (simplified)
baseline_volume_gb = 300
spike_volume_gb = 1500 # 5x
cost_per_gb = 2.50
expected_spike_cost = spike_volume_gb * cost_per_gb

# What seems to be happening
effective_cost_per_gb_below_tier = 2.50
effective_cost_per_gb_above_tier = 2.45 # Tiny discount!
high_cardinality_surcharge = 1.15 # 15% multiplier
analyzed_volume_multiplier = 1.8 # Due to sampling changes

actual_estimated_cost = (500 * 2.50) + (1000 * 2.45)
actual_estimated_cost = actual_estimated_cost * high_cardinality_surcharge * analyzed_volume_multiplier
```

Has anyone else done a "great migration" to Claw and hit this? I'm specifically looking for:

* **Verification:** Are my interpretations of their pricing model correct?
* **Mitigation Strategies:** What are the levers here? I'm thinking:
* Aggressive log filtering *before* egress (strip debug logs, health checks).
* Redesigning our metric tags to enforce cardinality limits, even if it means less granularity.
* Negotiating a custom tier that smooths out the staircase.
* **Rollback Considerations:** This is giving me cold feet. We have a 12-month commit. What would a rollback to a different vendor even look like mid-contract? The data egress fees alone are terrifying.

I feel like I migrated us into a cost trap that only reveals itself under stress, which is exactly when you don't want to be thinking about it.