Reading Observability Tools? That's a Robot's Job - Last Week in AWS Blog

Skip to primary navigation<br>Skip to main content

05.28.2026

Reading Observability Tools? That’s a Robot’s Job

By Corey Quinn

Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the…

FacebookTweetLinkedInReddit

Home Blog Reading Observability Tools? That’s a Robot’s Job<br>Prev

Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and that almost every design decision in the observability stack (including the framework most of the industry uses to describe its own job) was built for a reader who isn't sitting in the chair anymore.

I should probably explain a bit.

How We Got Here

About two weeks before the talk, my co-founder Mike Julian—the other half of Duckbill, the company that pays me to have opinions about cloud bills—went looking on the Anthropic dashboard for the per-user cost view that exists on every other SaaS product humans have ever bought. He could not find it. He asked the internet.

The answer came back from someone in customer-facing engineering at Anthropic, and it was… less than it could have been. There is no per-user cost view. Plans are flat per-seat. If you want cost estimates per user, you can—and I want you to feel the weight of this phrase the way I did when I read it—"hook up OTel."

The answer to a billing question was: get the OpenTelemetry SDK, wire up a collector, pipe the metrics into a backend, and build the dashboard you wish we had.

This is not the fault of the engineer who replied. She gave the customer-service-approved answer her org had set her up to give. The answer her company put in her mouth, though, is the most interesting / horrifying thing I've read on X The Everything App® this year, because it's going to be the right answer more often, not less. And that's not because vendors are lazy, but because the questions are getting harder, faster than the dashboards can keep up.

So everyone in that room—and most of you reading this—is about to wire up a lot of OTel.

The rest of the talk was about what happens after you do.

The Three Pillars, Translated Into English

Charity Majors has been arguing for the better part of a decade that "metrics, logs, and traces" is a marketing framework that observability vendors love and engineers should be suspicious of. She is, as is her habit, correct. Austin Parker made the same argument from the OpenTelemetry side last year: the three-pillars framing treats telemetry as three siloed signal streams when the whole point of OTel is that they're unified by shared distributed context. Honeycomb has been saying out loud, for a while now, that the pillars metaphor was architecturally wrong from the start.

My argument is narrower and meaner: even if you didn't buy that one on the merits, the audience for telemetry has changed in a way that breaks the framing for a second, independent reason. So now it's wrong twice.

Put more bluntly than the marketing pages can:

Metrics are for the human who wants to confirm a hunch.

Logs are for the human who has run out of better ideas.

Traces are for the human who finally gave up on the first two.

All three were designed for the same reader: A human. With eyes, intuition, and the ability to skim a dashboard and notice that the orange line is doing something the orange line should absolutely not be doing. And critically: with a finite amount of time, which means the visualization mattered as much as the underlying data.

That reader has been quietly replaced, and the seat is mostly empty now.

What's increasingly reading the telemetry is a process. It does not have eyes. And thus it can't skim nor tell at a glance that the orange line going up is bad and the green line going up is good. It does not understand your color scheme, a surprisingly common sentiment given most companies' "interesting" choices regarding color palette. It cannot appreciate the dashboard you cleverly built that arranges six panels in a way that tells a story to a senior engineer (who was likewise unappreciative of your hard work, but that's senior engineers for you).

But it can read attributes, follow trace IDs, connect dots, and of course it can grep, very quickly, across an enormous amount of structured data.

That is a profile of a reader, but notably it is not the reader any of these tools were built to serve.

The Two Pillars That Lose

Metrics: it's effectively an agentic dead end. A graph that says "errors went up at 3pm" is useful information for a human, who looks at it, mutters something uncharitable about whoever was on deploy duty, and goes to investigate. For...