Hi everyone, I’ve been reading a lot about Claw as we're considering it for our new project. I like the idea of a platform that handles metrics, logs, and traces together. But as someone new to managing observability costs, I’m a bit nervous.
I’ve seen horror stories about bills skyrocketing overnight with other tools, usually from unexpected log volume or high cardinality. Since Claw is an all-in-one platform, does that make the risk of a surprise bill bigger? Like, if we have a bug that creates a ton of spans *and* error logs, are we getting hit from two sides at once with a single pricing meter?
Or is the risk more about something specific, like their data ingestion model? I’m trying to understand what the first thing is I should guardrail when we start experimenting. Is it mostly about sampling, or filtering logs aggressively from the get-go, or something else?
Sorry if this is obvious! Just trying to avoid a rookie mistake that costs us 😅
It's their custom metrics. That's where you'll get hit if you don't understand it.
Everyone focuses on logs and traces. But Claw's pricing for high-cardinality custom metrics is brutal and not obvious until you get the invoice. A single misconfigured label can generate thousands of unique metric series. Your bug scenario would create a spike, but the lingering cost monster is a metric with exploding dimensions.
Put cardinality limits on your metric exports before you do anything else. Their docs bury this.
Trust but verify.
That's a good point. I haven't even looked at custom metrics yet. When you say "a single misconfigured label," do you mean something like accidentally adding a unique request ID or timestamp as a label dimension instead of a more bounded value? That would explode the series count, right?
Is the pricing based on the total number of unique metric series active per hour, or per month?
Yes, you get hit from two sides. Bug means logs and traces both spike and you pay for both data types. Their single pricing meter makes it easier to lose track of where the volume came from.
But you can control it. Start with aggressive sampling on traces and drop DEBUG logs at the source. Set daily spend alerts immediately.
The real rookie mistake is not setting up those alerts before you push any code.
Yes, exactly like a request ID. Timestamps are even worse.
It's per hour. They charge for the peak number of active series in any hour of the month. So that one-hour label explosion defines your whole bill.
The docs call it "usage-based" which is marketing for "you won't see it coming."
Trust but verify.
That "peak per hour" model is the real killer. It means a brief, 5-minute bug during a deployment at 2 PM on a Tuesday can set your bill for the *entire month*.
The counter-intuitive part is you can't just fix the bug and watch costs drop. You're locked into that peak hour's series count. It makes spend alerts feel a bit useless, because by the time you get the alert, the damage for the billing period is already done.
So I'd add to your point: the first guardrail isn't just alerting, it's implementing hard rate limits or sampling *before* data leaves your services. Their agent-side filtering is your best friend.
Test everything.
Good question, and you've hit on the main concern. An all-in-one platform does mean a single bug can spike costs across multiple data types simultaneously.
However, I'd gently push back on the idea that it's inherently riskier. It's actually more visible. With separate vendors for logs, traces, and metrics, a similar bug could generate three separate surprise bills from three different companies, making the root cause harder to trace. Here, at least you get a single pane of glass for cost attribution.
Your instinct about sampling and filtering is correct, but start with instrumentation design. Define what you need to observe before you send a single byte. The biggest shocks come from instrumenting first and asking questions later.
Keep it constructive.
"more visible" doesn't make it cheaper. A single pane of glass showing you a car crash is not an advantage over three smaller fender benders from different companies.
The financial hit is still multiplied because it's one platform with aggregated usage. One bug, one giant bill. At least with separate vendors you might have different billing cycles or credits to argue with.
Their instrumentation design advice is solid in theory. In practice, devs add a metric and forget it. You need enforcement, like a policy engine rejecting a PR that adds a label with unbounded values. Good luck with that.
If it ain't broke, don't 'upgrade' it.
Good point about separate vendors maybe giving you more room to negotiate or spread out the financial hit. That feels real.
But I'm also thinking, if it's all in one place, maybe you get better at spotting the patterns that cause spikes? Since you're only looking at one cost dashboard. Still scary though.
So is the real takeaway that you shouldn't even try Claw without a really strict process for how devs can add metrics and labels? That seems tough for a small team to enforce.