Several observability vendors have come out with “Frontend Observability” products recently, notably Grafana Cloud Frontend Observability, Honeycomb for Frontend Observability, and Observe Frontend Observability. The OpenTelemetry folks at the CNCF are also getting into this space, hosting a KubeCon Europe 2024 talk by Purvi Kanal, Senior Software Engineer at Honeycomb, entitled “From Real User Monitoring (RUM) to Front-End Observability with OpenTelemetry.” But wait, if “observability is the ability to collect data about programs’ execution, modules’ internal states, and the communication among components,” then it sits firmly within the backend domains of ITOps and Site Reliability Engineering (SRE). Historically, practitioners working in this space have leveraged Application Performance Management (APM) and observability tools to track metrics, logs, and traces in distributed systems and could care less about end users, right? I’m being facetious here, as observability vendors including Elastic, Datadog, Cribl, Dynatrace, Cisco, Splunk, and New Relic have all adopted the phrase “full-stack observability” in an effort to bridge into the developer world. However, as I have argued at some length, the “frontend” is weird. Market confusion around the word “frontend” and the perceived absence of a buyer make frontend observability a tough sell. I know of at least one vendor, Request Metrics, that has adopted and then abandoned the term frontend observability for this very reason. So what should we make of this new observability category? This post aims to address what frontend observability is; why today’s application developers might need it; and who is the intended user/ buyer.
RUMming up that Hill
Monitoring the frontend by way of the UI, browsers, and end users is not new. RUM (the most popular), Browser Monitoring, User Experience Monitoring (EUEM), Digital Experience Monitoring (DEM), and now frontend observability, all demonstrate an interest in the user-interaction layer. However, in years past tools for understanding how end-users perceive application performance have mostly shied away from the contentious, hipster term “observability.” So what’s changed? Frontend observability’s appearance signals deeper issues within this domain of end-user monitoring, and RUM specifically.
In the early 2000s, when it was introduced, RUM tools showed tremendous promise by capturing real-world performance and user behavior. The advent of RUM allowed teams to correlate customer reports with actual crash data, bridging the gap between user feedback and technical metrics. This correlation proved invaluable for troubleshooting and enhancing user satisfaction. Unlike APM, which often relies on synthetic monitoring that uses automated scripts to simulate user interactions and measure performance, by monitoring actual end users RUM established itself as the standard for assessing the true service-level quality experienced by end-users as well as identifying website errors or performance slowdowns. According to RUM advocates, while the synthetic monitoring approach provides baseline metrics, it lacks the nuance of real users.
Interest over time on Google Trends for Real user monitoring. 1/1/05 – 4/2/25.
Over the decades RUM has evolved, and has three major eras aligned with shifts in web architecture and user expectations. In the early 2000s, RUM focused on server-side rendered applications, where measuring document load times and backend performance was key for ITOps teams managing monolithic systems. As client-side rendering gained traction in the 2010s with the rise of JavaScript frameworks and public cloud adoption, RUM tools evolved to capture browser-side performance and JavaScript errors, catering to both ITOps and emerging SRE roles. In the 2020s, the complexity of single-page applications and cloud-native architectures has driven the need for RUM solutions tracing detailed front-end interactions and correlating them with full-fidelity backend traces, enabling ITOps and SREs to pinpoint issues across the stack. All of this sounds great in theory, but dissatisfaction with RUM has grown.
Despite advancements with RUM, dissatisfaction with these tools’ ability to adequately address UI performance and debug JavaScript has opened up the market to more targeted approaches—namely, frontend observability. The jobs to be done for frontend observability products is improving the experience of users, and this means optimizing the interface and interaction experience. This type of monitoring tracks user interactions through page load times, errors, AJAX and HTTP request speeds, and session duration. By analyzing this data, businesses gain insights into user experiences rather than just system performance.
There is also a pressing need for tools to move from merely reporting what happened to understanding why it happened. Instead of putting out fires, frontend observability aims to maintain seamless user experiences through prevention. However, delivering on this promise is not without challenges. For one thing, there is a question as to whether frontend observability tools are able to collect sufficient, high-cardiality data to offer meaningful insights without compromising user privacy. A second difficulty lies in observability’s cost. Like all monitoring solutions, tracking too much data can cause observability spend to skyrocket, so tools must strike a balance and not go overboard.
But wait, you say, wasn’t all of this the promise of RUM?!? Yes and no, but mostly yes. The relationship between RUM and frontend observability is complementary. Grafana’s marketing, for instance, suggests their frontend observability product is a wrapper around RUM. In a post “Introducing Grafana Cloud Frontend Observability” the title heading states: “Real user monitoring in Grafana Cloud: Get frontend error tracking, faster root cause analysis, and more.” I’ve also heard the phrase RUM-based frontend observability. So what is the difference? When I asked David Cramer, Co-founder and CPO at Sentry, about his thoughts on the frontend observability term he was dismissive:
It’s marketing. What I would tell you is monitoring has not changed in my entire career. Everything is still a log, or looks like a log.
What frontend observability sets out to accomplish is mostly RUM with a twist. My hypothesis about this marketing term is that it reflects the rise of the Frontend Kingmaker and the increasing importance of the frontend buyer.
Why Frontend?
In the past few years the term “frontend” has become a hot marketing buzzword in the observability space. Even vendors without a standalone frontend product are also elevating frontend in their content. Datadog discusses the importance of “Frontend Monitoring.” OpsVerse’s ObserveNow and OpenObserve both include frontend monitoring as part of their full stack observability approach, and Alerty claims to use AI to automate frontend monitoring. Other offerings that play in the frontend space include Embrace’s mobile observability solution “tying frontend mobile telemetry to backend performance data.”
Why this sudden interest in frontend? Observability vendors typically use the term frontend to describe a location in the stack. In this context, “frontend” is usually interchangeable with UI or end-user. It is also worth noting that the frontend observability movement correlates to the pivot toward a platform play happening at these Observability vendors. Grafana historically sold primitives, not packaged solutions, and it has only been in the past few years that they launched more managed offerings like their frontend observability product. Honeycomb is also marketing themselves as an “observability platform” in their headline messaging. But beyond how vendors define frontend observability in order to differentiate or subsume this category in relation to RUM (often treating it as a wrapper or platform for RUM), the issue of debugging and optimizing the end user’s experience remains difficult.
To sum up, the marketing term frontend observability positions vendors as interested in the user interaction layer. The solutions they offer improve on legacy RUM technology. What remains less certain to me is who is the intended user, and the Socio-Technical systems, meaning the “requirements spanning hardware, software, personal, and community aspects,” that have contributed to the appearance of this category in the present moment.
Why Now?
What is the experience of frontend developers when it comes to improving performance and fixing bugs? To begin, it is important to recognize that the signal for observability of the UI is inherently unclear. If I want to know when my app is broken or slow, this is rarely a boolean question of broken and not broken. An application’s UI doesn’t crash or fail to render necessarily, but frontend developers want to be alerted if the UI renders incorrectly or even just a little bit off.
Now let’s talk about JavaScript frameworks. The popularity of single page applications (SPAs) built using frameworks like React, which shifted the complexity of web applications from server-side to client-side, has resulted in richer and more interactive user experiences, while also necessitating changes in how developers monitor and understand application performance. Moreover, the rapid state of change in the JavaScript ecosystem means that developers and observability vendors alike are constantly on their backfoot when trying to trace and mitigate errors.
Another technological condition responsible for inciting the rise of frontend observability has to do with search and discoverability. When Google updated its Core Web Vitals to include load speed as part of its search ranking, it drove renewed impetus to improve app performance, often through RUM based tooling. Vendors like Request Metrics’s “Unified Performance Testing and Real User Monitoring” offer to improve how websites score on these. This demand for performance optimization extends to mobile. Mobile observability poses unique challenges not only in terms of the diversity of supported devices, but also for meeting performance demands enforced by ranking criteria for the Google Play Store and the Apple store. I’ve written that “Mobile App Development is Broken” before because the particular challenges faced by mobile developers, who very often self-identify as frontend engineers, are often firmly tied to end user experience.
Persona non Web Dev
All of this leads me to the weightiest challenge for frontend observability: the persona. Who in an engineering department owns it? Because frontend observability spans the domains of frontend and backend/ operations it threatens conventional divisions of labor. Should SREs and ITOps practitioners leverage these tools, or should they be the responsibility of frontend developers? When I spoke with Cramer about how Sentry is thinking about this issue he commiserated on frontend observability’s user/buyer disconnect:
SREs aren’t frontend developers. They’ve been trying to adapt OTel to make it work and to no one’s surprise it isn’t going well.
I also spoke with Austin Parker, Director of Open Source at Honeycomb and an OTel maintainer, about how the OTel community is thinking about frontend engineers:
Web and mobile performance people and backend performance people have very different mental models of performance and how to record performance data. What are the things they care about? How should those things be represented? You know, we’ve burned through a lot of highly skilled technical people in the OTel, real user, client SIGs, simply because there’s such a divergent set of expectations. It’s like two people that can’t agree on what color the sky is. And so it’s not really surprising, because if you’re a JavaScript person, you’re a browser person, and all you know is the horrible vagaries of the browser. Compare that to someone that only knows the horrible vagaries of the JVM, like, there’s not a lot of common ground, because the problems in your world and the problems in their world are very are just orthogonal problems.
Frontend observability’s persona problem is significant and it emerged early. In fact, Shawn Wang (swyx) and Charity Majors’s 2020 debate on the subject of “Observability for Frontend Developers” highlights the tension of whether frontend engineers can and should join the observability conversation.
Swyx learned about observability from an AWS podcast on the subject and realized there are “some tools that translate to that in my world.” However, after publishing a blog post on these overlaps he discovered:
I used the wrong word. I said observability in the title and of course whenever you mentioned observability on the Internet you [Charity Majors] show up.
It’s a good conversation, and what interests me especially is that swyx (who identifies as “a primarily front-end JavaScript type person”) and Charity (who has a background in operations and systems engineering), often seem to be speaking past one another. As the conversation progresses Charity expands on her ideas about what observability is and what it accomplishes using the language of ITOps, while swyx pulls from his frontend experience. Here’s one example of swyx trying to connect these discourses:
In my world [observability] maps very closely to user research … and so we have products for that [like] Fullstory, Hotjar stuff like that where we collect entire user journeys.
So, are Fullstory and Hotjar doing frontend observability? Not according to the vendors. According to Fullstory’s Dan Kuebrich, VP of Engineering, and Christian Lohr, Staff Technical Program Manager:
Fullstory is a Digital Experience Intelligence (DXI) company. We build a product that serves as x-ray vision into users’ digital experiences by providing session replay and product analytics.
Fullstory does not do observability: check. But the goal of understanding end-user experience persists, but the means of accomplishing it (session replay vs metrics, logs, and traces) differs. I don’t think swyx is off base to note this connection though. In fact, although Fullstory does not market itself as an observability tool it has breached this market through strategic partnerships with New Relic and LaunchDarkly. The implications of this division are logistical within engineering organizations: session replay is the concern of frontend developers, but monitoring is not.
I highlight swyx and Charity’s debate five years later because the observability folks, who have historically kept themselves separate from frontend engineering’s tools and ideas, are now signalling an interest in the frontend. If they want to play in the frontend court to cultivate this segment as buyers they will need to find common ground to foster productive conversations.
Who is Frontend Observability for?
Observability vendors seem to be confused—sometimes self-consciously, and other times obliviously—about what segment of practitioners within engineering teams will find frontend observability attractive. Will JavaScript developers like swyx use frontend observability tools, or will these products augment the ITOps and SREs already in charge of monitoring application backends? Determining this will go far toward making these products successful.
Establishing who frontend observability is for matters. If vendors opt to target frontend observability to SREs then they will need to convince them of the end users’ importance. On the flip side, because frontend engineers require very different forms of support and marketing than observability’s traditional targets of ITOps and SREs, if they opt to target these consumers, vendors will need to dramatically shift their marketing and support. At the very least JavaScript developers will have to be upskilled to be successful in this space.
The promise of frontend observability is a future in which developers can not only detect issues but also provide actionable recommendations to mitigate them. This is a boon for businesses, and will benefit entire engineering teams. However, the fact of the matter is that without clearly defined and cultivated potential users, few teams will invest in these pricey tools or services.
Disclaimer: Google, Honeycomb, Launchdarkly, Sentry, Elastic, Cribl, Dynatrace, Cisco/Splunk, Sentry, Observe, and Embrace are all RedMonk clients.
Header image from Kate Bush’s Running Up That Hill (A Deal With God). 1985. YouTube.
No Comments