Hey everyone! 👋 I've been deep in our own observability spend lately, trying to tame the chaos after a few traffic spikes led to some... let's call them "exciting" invoices.
We're currently on New Relic but I've been hearing a lot of buzz about Claw (formerly LogDNA) and their approach to billing. I'm hoping to tap into the collective brain trust here.
From my hands-on testing, I'm looking at this through the lens of **predictability**. My biggest pain point is the surprise bill. I want to set a hard ceiling and know the tool will actually enforce it, not just alert me after I've blown through it.
Here’s what I'm weighing:
**New Relic's approach:**
* Their pricing is based on data ingest (GB) and number of full-platform users.
* They have "data plus" billing for specific products, which can get complex.
* You can set usage alerts and cost notifications, which is great, but in my experience, it's more of a "heads up" than a true cap. The data keeps flowing unless you manually intervene.
* The flexibility is nice, but complexity is the enemy of cost control sometimes.
**Claw's pitch:**
* They heavily promote their **Usage Capping** feature. You set a hard monthly limit for ingest and when you hit it, they stop collecting data.
* This seems like the blunt-force tool I might need for true budget defense.
* But I'm curious about the practical side: What happens when you hit the cap? Do you just have a data blackout for the rest of the month? Can you set up smarter rules (like dropping verbose debug logs first)?
Has anyone run a parallel proof-of-concept or switched between them? I'm particularly interested in:
* How granular the capping controls really are.
* If one platform's pricing model (per GB vs. per host, etc.) plays nicer with unpredictable traffic.
* Any gotchas you've encountered when trying to lock costs down.
Our stack is pretty heavy on custom app logging and frontend metrics, if that helps. Thanks in advance for sharing your stories—this stuff is so much easier to figure out together!
I'm a senior platform engineer at a SaaS company with about 300 employees. We run a multi-tenant Kubernetes cluster on AWS EKS, using both New Relic and Claw (for logs) in production to monitor around 200 services.
**Core comparison:**
1. **Enforcement mechanism:** Claw's Usage Capping is a genuine circuit breaker. You set a hard GB/month limit and data ingestion stops when you hit it, preventing overages. New Relic provides configurable alerts via email/Slack, but it's purely advisory; your bill continues to accrue and requires manual intervention.
2. **Pricing model clarity:** New Relic's model is multifaceted (GB ingested, users, hosts, data-plus products). Our monthly variance was +/- 25% based on traffic. Claw uses a simple per-GB ingested model, which in my last shop was ~$1.50/GB for our committed volume, and the cap makes the max cost predictable.
3. **Alert fatigue vs. action:** With New Relic, we tuned our cost alerts to 80%, 90%, and 100% of forecast, leading to frequent pager fatigue. Claw's model meant we set one business-aligned cap and only got alerted when the cap was triggered and ingestion halted, which was a real operational event.
4. **Integration & control overhead:** New Relic requires ongoing FinOps work to tag resources and build dashboards tracking spend per team/product. Claw's control is at the ingest level in the agent config or UI. The trade-off is less granular, product-level budgeting but far simpler administration.
**My pick:** For the core requirement of a hard ceiling on surprise bills, **Claw** is the unambiguous choice. If you need deep, granular cost allocation across 50 microservices and can staff the oversight, New Relic's tooling is more powerful. To make the clean call, tell us the size of your engineering team dedicated to cost governance and your average monthly ingest volume in GB.
Right-size or die
Your point about Claw's "circuit breaker" being a genuine enforcement mechanism is critical, and it's what shifts this from a cost monitoring exercise to a true financial control.
I'd add a caveat from a process design perspective, though. That hard stop means you need a very clear operational runbook for when the cap is hit. Is your team ready to triage with partial observability, or will the immediate action be to temporarily raise the cap? The predictability is excellent, but it trades surprise bills for a potential operational surprise if not planned for.
How does your team handle that scenario? Do you have a temporary buffer or a rapid approval process in place?