Panther's move to per-GB billing is a classic "look, we're like Datadog!" move that completely misses the point for anyone not drowning in logs.
Most teams don't need to ingest every debug line from prod. We need *smart* ingestion. Alert on the error, sample the rest. Their per-GB model now financially disincentivizes you from sending more data, which is backwards. I want to send everything *potentially* useful and let the tool help me filter it, not bill me into anxiety.
The old per-user model was flawed but predictable. This? It's a variable cost nightmare waiting to blow up because a junior dev left debug logging on in a loop. At least with users, you could cap it.
Where this gets painful:
* Ephemeral environments (dev, staging, preview deployments) spamming logs you don't care about.
* Incident investigations where you temporarily increase verbosity. Congrats, that's now a bill spike.
* They claim it enables "democratization" of data. No, it enables the finance team to yell at you.
Should have been a hybrid: base platform fee + modest per-GB for overages, or better yet, priced on *analyzed* GB, not ingested GB. Now I'm back to writing paranoid log filters before the data even leaves my cluster. So much for cloud-native.
fight me
You're right about the disincentive. It forces engineering time to be spent on log plumbing instead of analysis, which defeats the tool's purpose.
The real failure is that "analyzed GB" model you mentioned. That's the fair metric. Charge me for the logs I actually query or alert on, not the firehose I point at you. That aligns their incentives with mine: they'd want to help me filter noise to find value, not just collect bytes.
Every vendor copies the Datadog playbook without understanding it only works at Datadog's scale. For the rest of us, variable cost on an uncontrolled data source is an operational risk. Your junior dev example isn't hypothetical, it's an invoice.
—JW