Operations | Monitoring | ITSM | DevOps | Cloud

Modern systems are wonderfully capable, but relentlessly complex. Debugging across microservices, frontends, and cloud edges often means switching between five or more tools, trying to stitch together “what changed” and “why it broke.” Honeycomb’s wide events model has proven to be a superpower for taming that complexity, by allowing you to easily observe and query end-to-end traces without worrying about how much granular data you attach to your events.

Modern engineering teams face a persistent challenge: knowing when something goes wrong before their customers do. With microservices architectures sprawling across dozens or hundreds of services, creating comprehensive alerting becomes an overwhelming task. You're left playing whack-a-mole with manual alert configurations, often missing critical issues or drowning in false positives.

If you’ve been following my public journey with LLMs this year, it probably won’t surprise you to learn that this blog post is an announcement about the general availability of Honeycomb’s hosted MCP server. I want to share a few updates about what’s new in the GA release, discuss some interesting learnings from building it, and share examples of how we’re using MCP internally. First: if you're still in the dark about MCP and AI agents, go read the earlier blogs I linked.

I’m a product engineer at Honeycomb. While my work spans the stack, I’m currently focused on deepening my frontend expertise. To support this, I’ve been using ChatGPT as a study assistant. It’s helped me break down complex topics with clear explanations, real-world examples, and—critically—interactive practice. The most effective formats I’ve found.

As an engineer on Honeycomb’s frontend platform team, I’m constantly trying to understand and improve our web performance. And I have a whole lot of questions. I tried answering these types of questions without Honeycomb in the past, and it was difficult and time consuming. It used to take me days to identify performance issues and their causes, let alone fix them and confirm that they improved web performance for some subset of users.

Observability tools like Honeycomb are built for engineers, not PM teams… but that doesn’t mean there’s no benefit to having your PMs in Honeycomb. Whether it’s debugging a weird customer issue or tracking how a feature is used in the wild, observability gives PMs something traditional product tools can’t: real-time answers with full context, down to a single user.

If your organization is anything like ours, then you’ve probably embraced using large language models like Claude. Just last week, we gave all Honeycomb employees access to Claude. Now, developers can generate AI-assisted code, product managers can perform analysis on customer usage trends, marketers can test messaging, sales can do customer discovery and we are shipping AI-powered features to improve user experience.

We're thrilled to announce that Honeycomb Tags are now generally available across SLOs, triggers, and boards! Over 100 customers are already actively tagging their observability resources in Honeycomb today.

You just shipped your latest frontend release. It passed QA, CI ran, and it looked great in pre-production. But now it’s live and users are hitting an unexpected error: TypeError: undefined is not a function in Chrome. Your error tracking tool flags the exception. You get a stack trace, some breadcrumbs, maybe a session replay.

Every day I seem to run into yet another post with someone solemnly opining that “writing code has never been the hardest part of software engineering. And hey, that’s smashing. As an engineer from the ops/infra/SRE side of the house, I feel like I’ve been saying this my whole career. (Is there anything more satisfying than being proven right in public? Not in my book.) So, which is it?