What no-surprises o11y billing should look like

First, let's preface that observability shouldn't be a cost centre to reduce to 0, it should be a tool that generates value, that you invest in until you get diminishing returns. But, it's really hard to measure ROI when you don't know how much it's going to cost, or if you're forced to limit how much telemetry you send in the moment you most critically need your observability.

Flexibility and control

Predicting how much you will spend on observability starts by setting a baseline of traffic - how much traffic you want to send, on average, and how much you want to de-deduplicate redundant data. You shouldn't need to keep every single HTTP 200 that took less than 100ms, you just need a few to serve as relevant examples. You do want to keep 100% of HTTP 500s, and 100% of slow requests. This is what dynamic tail sampling is for.

Honeycomb solves this problem in a turn-key fashion by offering Refinery. It runs inside of your cloud account, and you set a target event egress rate, control the configuration and can turn up or down the volume on things that are or more or less valuable to you. And the resource consumption essentially scales linearly with the amount of traffic you put through it. No charge from us to you, just a gift of the ability to cut your Honeycomb bill 10x or more right from the start. No mystery-meat algorithms or "where did that trace go?".

Visibility into event volume

You should be able to know at all times what's generating traffic being sent to your provider. This starts at the environment, service, or dataset level.

But attribution per service isn't enough. What about being able to dig in by span name, or even user id or status code, using the tooling to aggregate a COUNT of ingested events, which are the exact same as the key billing dimension?

Pre-payment, not post-payment

Observability should be something that you can forecast in advance, and tune and refine over time, rather than a reactive "where did the surprise credit use come from" murder mystery. You shouldn't need observability tools for your observability tools. Buy a block of events (trace spans post-sampling), lock in a rate for those events. Using more than you thought you would over time? Talk to your provider.

Honeycomb Enterprise subscriptions are offered in 1, 2, or 3 year terms. You pick how many events you want to buy for each contract year. And we're flexible if you look like you're on track to incur overages - first, you'll start getting emails warning that you exceeded daily target, then your account manager will reach out, and we'll work together to tune your sampling. But if adoption takes off inside your organisation, no sweat, we're open to early renewal conversations or moving events between contract years. The last thing we want to do is to stick you with an overage, we're here to make our customers happy over the long term rather than trying to make a quick buck.

Burst protection

High-traffic days happen. Rather than having to choose between shutting off the traffic and flying blind, or eating a big bill, your observability provider should meter based on a percentile of your net consumption, not sum total or peak consumption. Why get surprised if your number of metrics spikes due to a cardinality increase, or you get Slashdotted, or it's simply Black Friday?

Honeycomb offers up to 3 days of "burst protection" usage per month where if you consume more than 2x your projected event target, you only get billed for 1x the event target. Breathe easy. We've got your back.

Predictability breeds confidence

Honeycomb wants to be the tool that's always there for you, that you can count on to deliver insights. This is how we help our customers understand their bill and know that they've made the right investment.