Operations | Monitoring | ITSM | DevOps | Cloud

Enterprise software has moved past the generative AI testing phase. Businesses with millions of daily users or workloads are no longer just prototyping LLMs in a vacuum. They’re directly wiring agentic efficiency into product interfaces and infrastructure to stay competitive. This wave is often compared to the spread of microservices in the past, but we aren’t just adding new dependencies and complexity.

At Honeycomb, we’ve been using Claude Code across our engineering team for a while. Anecdotally, I had a sense of who the power users were, and I had seen some examples of complex usage. But I wanted to be able to confidently answer questions, like: Claude Code supports OpenTelemetry out of the box, which means sending telemetry to Honeycomb takes just a few minutes of configuration.

Since Honeycomb started, it has had a weakness: too many choices. Every field, custom or standard, hundreds of them, all are free to group, filter, and visualize in dozens of ways. Which ones are interesting? Honeycomb exists to help people understand custom software. It doesn’t pretend to know what matters in your application. That’s an interpretive task, not programmatic. Hey, computers can do interpretation now!

Let’s start with a question. What is DevOps all about? I’ll tell you my answer. In retrospect, I think the entire DevOps movement was a mighty, twenty year battle to achieve one thing: a single feedback loop connecting devs with prod. On those grounds, it failed. Not because software engineers weren’t good at their jobs, or didn’t care enough. It failed because the technology wasn’t good enough.

OpenTelemetry makes it easy to produce and transmit any type of telemetry. In production environments, this often means deploying the OpenTelemetry Collector as an intermediary to process, enrich, and route telemetry data. As systems scale, so does this infrastructure—sometimes to hundreds or thousands of Collectors spread across environments.

If you’ve ever stared at your observability bill and whispered “there’s no way this is real,” congratulations! Your instincts are working.

So you've built a client application and you've started sending telemetry. The information sent back by this client is vital to you, and one of the first things you care about is capturing and reporting errors. There are at least two ways to report error details in OpenTelemetry. Web applications generally place exceptions in trace spans as span events, and mobile applications send exceptions as log messages instead.

If there’s one thing clear from our AI-powered observability webinar, it’s that observability has officially graduated from a “nice-to-have” to a business-critical discipline, and AI is helping lead that charge. Our webinar brought together guest speaker Stephen Elliott, Group VP at IDC, and Ranbir Chawla, former SVP of Engineering at RB Global, for an hour of insights that mixed data, experience, and hard-won lessons from the trenches.

When troubleshooting complex software, it’s important to be able to gain insight via its telemetry quickly and precisely. No one wants to waste time switching between tools or worrying about how to interact with different types of data. At Honeycomb, all your data is available in one place, accessible via our fast query engine. But what does that look like in practice?

SaaS products that are built for engineers power critical workflows, yet their designs are often afterthoughts. SaaS products often assume that technical audiences will figure out their way through a complex experience, or just forgive them for the paper cuts on the way. A foundational design system can be perceived as a layer of polish rather than an infrastructure investment, especially in the early stages of a startup.