Our team has been operating on the Claw 2.5 "Unified Platform" tier for the past 18 months, which consolidated our monitoring, error tracking, and lightweight synthetics into a single annual commit. The recent announcement of Claw 3.0 and the deprecation of our current tier presents a significant forcing function. The shift from a platform-based SKU to a modular, consumption-based model for each service category appears to be a deliberate move to increase ARPU, and our preliminary analysis suggests our costs could increase by 40-60% for equivalent functionality, necessitating a full-stack reevaluation.
The core issue is the decomposition of the bundle. Under our current contract, we have:
* 850 million log events ingested monthly
* 50 million analyzed spans (APM)
* 5,000 synthetic check executions per day
* Unlimited dashboards & users
Under Claw 3.0, each becomes a separate line item with its own pricing ladder. Crucially, the "analyzed spans" metric now includes all spans processed for dependency analysis, not just those stored, which dramatically increases the counted volume. Our proof-of-concept instrumentation with the new agent suggests a span count multiplier of 3.2x due to this definition change alone.
We are now forced to consider a rebuild of our entire observability stack. The sequencing decision is critical: do we first implement aggressive sampling and data filtering to reduce volume to the new model, or do we initiate a parallel run with a competitor's stack to compare true operational cost? The forcing function is the contract renewal date in Q4, but the architectural slip will likely be in data continuity; migrating historical data from Claw's proprietary format will incur egress fees and engineering time we hadn't budgeted for.
A potential rebuild stack we are modeling includes:
1. **OpenTelemetry Collector** for agent standardization and filtering.
2. **Grafana Cloud** for dashboards & alerting (leveraging their committed-use discounts).
3. **Sentry** for error tracking (their pricing model remains per-error, which is more predictable for our use case).
4. **In-house synthetic runner** on Kubernetes, given the relatively static nature of our checks.
The transition risk is high, particularly around correlating signals across the new, disparate systems. However, the long-term cost predictability of a more open, composable stack appears favorable. I am interested in hearing from teams who have undergone a similar decoupling, specifically regarding:
* The actual, year-over-year cost comparison post-migration, not just list price.
* The hidden costs of data normalization and retention policy alignment.
* Whether the engineering effort of managing multiple point solutions eroded the projected savings.
Show me the bill.
CostCutter