RUM can leave questions unanswered.
Honeycomb for Frontend Observability doesn’t.
Frontend development has evolved rapidly over the past decade, but one challenge remains constant: understanding what’s happening in real-time across diverse browsers, environments, and user interactions. This is where observability steps in—but how does it apply to the frontend world where user experience can break in countless, unexpected ways?
To dive deeper into this topic, Emily Nakashima, VP of Engineering, and Charity Majors, Co-Founder and CTO, sat down to discuss the current state of frontend observability, common misconceptions, and how it’s changing the way developers work. Emily and Charity share their insights on how frontend developers have been quietly pioneering observability and what the future holds for this essential practice.
Q&A with Charity and Emily
Charity: What drew you to observability from the frontend perspective?
Emily: I came to it the old fashioned way and probably the same way you did—through anger. When I was an engineering IC, I primarily worked on the frontend. Years ago, I was working on an e-commerce project, and the leadership team came to me and said, “The site is too slow and it’s reducing conversions. Fix it.” I thought that sounded like an important problem; I’d better get on it. So I started to optimize our frontend code, but I didn’t want to do it blindly.
I had friends on the ops team, and I had seen their monitoring tools. I was reaching for the equivalent on the client side, but found that the tools were not on the same level. We had a single page app and it was very hard to figure out anything beyond page load time. In modern web applications, that often isn’t the most meaningful metric. I went down the rabbit hole looking for a better tool, and that journey was a huge part of why I ultimately came to Honeycomb. With effort, you could get that visibility I was chasing after in Honeycomb—but until now, we didn’t make it very straightforward to do.
Charity: What’s the current state of observability in the frontend world?
Emily: This is such a funny question because frontend developers rarely use the term “observability,” but I think, in many ways, they are pioneers in this category. Frontend engineers have always needed to know when something breaks in their code, and they often find out in the most painful ways. Backend engineers get immediate feedback via monitoring and alerts, so they can often deal with customer problems in aggregate. Frontend folks deal with the pain directly because they don’t always have tools that tell them—they get the angry support tickets and complaints on social media. And to get ahead of this, they’ve been cobbling together observability from different tools for a long time: error monitoring, analytics, session replay, metrics, RUM, and everything in between.
Charity: Right, frontend engineers have always been in it in real-time with users. Unlike backend developers who could go years without really interacting with the end-user, frontend engineers feel every bug, every UI glitch.
Emily: Exactly. Frontend developers think most immediately about the user experience. In a funny way, I feel like frontend and ops-focused teams have the most in common of the engineering disciplines because we know what’s actually causing pain and we have to respond to it. We also know to blame the network.
Charity: It’s always a network problem.
Emily: Exactly. Anyway, these teams know the reality of what users are dealing with because they hear about it most. And while frontend engineers may not use the term “frontend observability,” when they describe their tools, you can see there’s such enthusiasm in the market for understanding user experiences in an immediate, direct, flexible way—just like we’re hearing from the more leading-edge operationally-oriented teams like SREs.
Charity: What do backend-focused developers tend to get wrong about the frontend?
Emily: If you think back to the 2010s, there was this perception that frontend was maybe simple or easy and backend was hard. I’m glad that this has become an outdated notion, and I think a lot of people have made peace with the idea that they’re both hard—or, if anything, sometimes frontend is more complicated due to the pace of change. The frontend deals with diverse environments—different browsers, third-party JavaScript, and so much that’s outside a developer’s control.
Charity, it reminds me of something you’ve talked about in the context of AI and working with LLMs: it’s easy for developers to believe their code doesn’t change between releases, but we know there are a hundred different ways that this isn’t true in modern web applications. They rely on third-party services, they have feature flags, they deploy third-party javascript, they don’t have repeatable builds, their users run browser extensions or update their browser version—the list goes on. We’re chipping away at that idea of code not changing between releases every day. LLMs are just one big and obvious way; the client-side execution environment is another.
Charity: Yeah, frontend work has to contend with a lot of external factors. It’s not like backend work where you control the server and the environment. Frontend engineers know their code will run alongside other unknown code, and it’ll change between deploys—sometimes at a moment’s notice.
Emily: Exactly, and I feel like that’s the secret problem no one wants to talk about—that your code is changing all the time. So, even if you think, “I’m so smart, I’m never going to deploy on Friday,” some third-party tool might. Suddenly, you’re dealing with an afterhours issue without any warning—just like the ops team. Frontend and operational teams are BFFs in this shared pain.
Charity: If there isn’t a tradition of “observability” per se in frontend, how do people find these tools?
Emily: I think a lot of us have experienced a there-has-to-be-a-better-way moment. Frontend developers are used to their tool chain evolving very quickly, so they’re better than most at realizing there’s a need for a new thing and searching for it. There are aggregated tools that give a general sense of what’s happening in production, but when you get that one support ticket from “James72 in Nebraska,” aggregated data doesn’t help. You need to get granular.
Charity: Right! The magic of high cardinality—frontend developers need tools that can handle a ton of unique identifiers like user IDs or session tokens. Top-10 lists are a great starting point, but not when the issue you’re looking for might be number 70. In distributed systems, everything is broken all the time. Just because your graphs are green doesn’t mean your systems are fine—it probably means your granularity sucks. Aggregated data is like knowing the average color of the Mona Lisa is puce—how useful is that? Not very. For every user-reported issue, there are likely hundreds more going unnoticed. Frontend observability lets you get ahead of these.
Emily: Right, and it’s not just about finding bugs. It’s about understanding each user’s experience in real-time. You need to know what’s working for them in the experience and what isn’t so you can improve continuously, not just fix an error here or there.
Charity: What challenges do frontend developers face when adopting observability?
Emily: I think there are two challenges. On the conceptual side, I think that the terminology used in the world of observability wasn’t designed with frontend developers in mind. For instance, we talk about ‘events’ in terms of telemetry, but frontend developers think of DOM events in the browser. We love Service Level Objectives, and in the frontend world, there’s maybe more of a sense of performance budgets as the way to measure attainment against a performance goal.
Charity: True—so, there’s definitely some translation that needs to happen and figuring out how to talk across that boundary. And the other challenge?
Emily: The brass tacks challenge is often budget. Frontend teams frequently struggle to get the budget for the right tools. The platform team often owns the giant cloud bill and might be able to sneak in one more tool without anyone noticing, but frontend teams often still have to fight for the resources they need. And frontend development has become much more complex, but not every organization has acknowledged this by investing in robust tools. The budget payoff is there, but it’s a matter of getting leadership to see the value.
Charity: This is where I feel a lot of frontend teams are at the cutting edge of using observability not just for fixes but for knowing what users are experiencing. And I think observability is part of bringing your frontend team up above the value line.
Charity: What do you think frontend developers will appreciate most about Honeycomb for Frontend Observability?
Emily: I’m really excited about how observability can help frontend teams be more proactive. It’s not just about fixing issues—it’s about creating great user experiences with the data you’re gathering. And it’s not just about application data anymore—it’s also about security, performance, and even product analytics. Frontend developers are sitting at this unique intersection where they can gather all of this data and use it to make the experience better for users. That’s what’s so exciting about the future of frontend observability. Frontend teams can see who’s using which parts of their product, what’s working, and where they should double down to invest more and pursue something new.
Charity: That’s such a key point—observability is no longer just about fixing what’s broken. It’s about asking, “What’s really going on?” and getting ahead of issues before they snowball. I think that’s why tools like Honeycomb are so powerful; they let developers keep their finger on the pulse of the entire system.
Emily: That’s what excites me about Honeycomb for Frontend Observability. It gives developers the tools to make the end-to-end experience better for the user—to really understand the entire lifecycle of user interaction.
Charity: Right, and having everything in one platform means engineers are empowered to explore. I’ve always believed that the boundaries between tools are what create silos. When everyone has their own view of reality, you end up spending more time debating those views than actually solving problems. Observability is breaking down the silos between teams and giving everyone a unified view of reality. Whether you’re in frontend, backend, or ops, the tools are converging and the insights are becoming more powerful than ever.
Emily: Yep, it’s a single source of truth for all of engineering. It removes the friction of teams looking at siloed data—one team looking at logs, another looking at metrics. With unified data all in one place, everyone is working from the same information to make decisions.
From nice-to-have to essential
Frontend observability is no longer a nice-to-have—it’s now essential for delivering great user experiences in today’s lightning-fast, ever-evolving development landscape.
As Charity and Emily highlighted, frontend developers have been the unsung heroes of observability for ages, navigating the complexities behind the scenes. But now, with the right tools in their toolkit, they can proactively monitor, diagnose, and elevate their systems to new heights.
If you’re still on the sidelines when it comes to observability in your frontend projects, it’s time to jump in. Embrace the change and empower your work—your users will thank you!
