What Is Real User Monitoring in an Observability World? It Is Not APM "Agents" - Part 1

Eric Futoran
Embrace
Learn more about Embrace

Agent-based approaches to real user monitoring (RUM) simply do not work. If you are pitched to install an "agent" in your mobile or web environments, you should run for the hills. The world is now all about end-users. This paradigm of focusing on the end-user was simply not true a few years ago, as backend metrics generally revolved around uptime, SLAs, latency, and the like. DevOps teams always pitched and presented the metrics they thought were the most correlated to the end-user experience. But let's be blunt: Unless there was an egregious fire, the correlated metrics were super loose or entirely false. Instead, your teams should prioritize alerts, monitoring, and work based on impact to the end-user, as it directly affects your businesses. And your developers and DevOps teams should collect data, monitor, prioritize, and resolve issues accordingly.

The agent-based RUM problem

"Agents" are a mechanism that does not work in the current end-user centric world. They were born out of shimmying the principles of the backend to mobile, web, and the myriad of other ways users interact with the world. Let's compare the difference between user environments and backend environments: ■ User environments are open, unstructured, and uncontrollable as they are unowned devices and browsers with the central figure being an unpredictable user. ■ Backend environments are closed, structured, and controlled as they are composed of relatively homogenous physical and cloud applications. With closed systems that have fewer external variables, agents focus on a known set of errors to monitor and to trigger data collection for resolution. However, monitoring systems outside of the backend is complex because there are a multitude of types of errors way beyond crashes, error logs, network traces, and API errors. In an observability world, real user monitoring is about collecting "all" the data for every session — good or bad — and not just a sampled set based on predefined error types. Only by collecting the entirety of every session can the best vendors have the opportunity to analyze and provide the utmost value to your teams. These vendors have evolved beyond agents to surface every type of user-impacting issue, help resolve them by comparing against good sessions, and prioritize overall impact across the complete set of issue types. For example, the same crash for two different users could have different root causes because of the environments, third-party SDKs, and API timeout parameters. To hit the difference home, watch a developer, outside of DevOps, open a RUM dashboard for a vendor who uses the agent-based approach. The core dashboard will have the following: ■ A geographical map laying out the incidents ■ A generic list of error logs and crashes ■ Some sort of mapping of network errors ■ A single health score The developer reviewing this dashboard will not come back to it regularly or at all. And it's not hard to see why. The dashboard does not tell them which users are affected, where to prioritize their efforts, or the types of bugs and optimizations that they should care most about. It's not built for them from the data collected to data organization and display. There is a reason why these developers always implement and use other vendors — even for simple concepts like error logging and crashes — alongside those application performance monitoring vendors. Let's deep dive into the core differences between these approaches and explore what a true real user monitoring methodology looks like. That way, you will know it when you see it and can create the best experience for your end-users as well as your developers and DevOps team.

The spider web problem

To illustrate the core implication of an agent mentality, let's focus on the "spider webs." You know the ones I'm talking about. You've seen the cool demos with a picture connecting nodes across your systems to demonstrate "visibility" across all the apps running on your servers and machines. Everything is connected by an ever-expanding spider web of nodes and lines — every app, compute instance, API call, etc. Oh, it's very pretty to see all the apps and API calls going to and from each other. It's also a nice source of confidence that the agents are collecting the data required to monitor, identify, and resolve potential issues. However, the very nature of this mental model of a spider web is it assumes all the issues occur on the lines between the nodes or on the nodes themselves: ■ An increase in network latency means you should look at the connected database, server, or service calls. ■ An increase in downtime means you should look at the connected servers to see if they're under heavy load. ■ An increase in transaction failures means you should look at the connected service calls for a point of failure. The paradigm of agents is one of looking for a closed set of known symptoms for broken apps, failing processes, and poorly designed code. To help resolve these symptoms, the agents collect samples of app and process information, so that when an API throws an error or a process has downtime, the agent collects the corresponding data in reaction to the error. And this approach works … on the backend, for a known set of errors, in a controlled environment, with little external pressure from the outside world. But when applied to the client side of web and mobile, what happens when the complexity explodes?  What happens when there are an infinite number of unknown pressures, from the users, the devices, the operating systems, the app versions, the network connectivities, and the other apps running? How do you truly understand your team's effectiveness when the biggest issues are not related to downtime or following individual service calls throughout a distributed system?

The problem with uncontrolled environments

Uncontrolled environments are any digital experience that's external to data centers. Beyond just smartphones and web browsers, they're point of sales, VR and AR devices, tablets in the field, and smart cars. And the world is increasingly one of uncontrolled environments for business-critical touchpoints. The most effective developer and DevOps teams monitor these client-side environments with early warning systems to determine when users are impacted so they can triage and resolve issues. They flip the traditional application monitoring paradigm. ■ Traditional application monitoring: Sample data by looking for a known set of errors, then gather context around them. ■ Modern application monitoring: Gather data without knowing its full value, correlate those data points to user impact from the end-user vantage point, then determine the error, measure the impact in order to prioritize it, and route it accordingly. In order to collect, identify, and resolve errors correctly, DevOps teams must understand the challenges that come along with running apps in these types of uncontrolled environments. After all, the assumptions about where failure points can happen are vastly different. Start with: What Is Real User Monitoring in an Observability World? It Is Not APM "Agents" - Part 2

Eric Futoran is CEO of Embrace

Related Links

Hot Topics

Related Vendors

The Latest

AI is Moving Fast, and Enterprise File Data Is Not Ready

Pilots are everywhere, stakeholders are seeking results, businesses are pushing for new tools, and IT teams are being asked to make AI secure, reliable, and useful at scale. But as organizations move from testing AI to operationalizing it, many are discovering that the biggest barrier is not the model, the use case, or even the budget. It is the file data foundation within ...

Move Fast Without the Usual Quality Penalty

Fast or cheap? For most of my career in engineering, speed and quality sat on opposite ends of a seesaw. The "OR" in "fast or cheap" was non-negotiable. It was expected that pushing for faster releases meant that something in quality would give way. Tightening quality controls meant the schedule slipped. Every engineering leader I know has lived some version of that tradeoff ... The seesaw is starting to level out ...

When the Observability Bill Arrives for Agentic AI

I have been building enterprise software for more than 20 years ... One thing stays true across all of it: You do not find out your foundation is wrong during the crisis. You find out when the debt comes due. For a lot of organizations, that bill is arriving now. New research ... puts hard numbers on something practitioners have been sensing for a while. The telemetry problem isn't coming. It's already here ...

AI is Breaking Enterprise Log Management

The rapid growth of AI workloads is pushing traditional log management approaches to their limits, according to The State of Log Management 2026 report from Dynatrace. Modern logs have become critical to understanding, validating, and securing AI-driven decisions, helping organizations ensure reliability, compliance, and performance at scale. However, the volume and complexity of AI telemetry are overwhelming legacy tools ...

How Edge Intelligence Will Redefine Secure Connectivity

For years, secure connectivity has relied on a familiar pattern: route traffic back to centralized gateways, inspect it, and then allow access. This model worked when applications lived in a handful of data centers and users were largely confined to offices. That model is now under strain. Applications are distributed across clouds, users connect from everywhere, and real-time workloads demand performance that centralized inspection points struggle to deliver. As traffic volumes grow and latency expectations shrink, routing everything through a small number of control points has become both a performance bottleneck and a resilience risk. The future of secure connectivity requires a different approach ...

Production Inference Shifts Decisively to Private Cloud

The AI experimentation phase is over, and the private cloud is where enterprise AI workloads are being deployed for security and scale, according to Private Cloud Outlook 2026, a new report from Broadcom ... 2026 marks an acceleration into a full AI tipping point. The shift is being shaped by three forces — costs, complexity, and control — that public cloud environments are increasingly failing to address for production AI at scale. Key findings from the report include ...

Why DevOps Teams Build GenAI Tooling While Most Organizations Still Rely on Manual Monitoring

44% of organizations have reported an outage in the past year tied to suppressed or ignored alerts, and 78% had at least one incident where no alert was fired at all ... Engineers learned about failures from customers. That gap between what our tools report and what our customers experience is the problem DevOps teams have been quietly solving with GenAI tooling, even as most enterprises continue to run their NOCs on manual alert triage ...

Why Cloud Reliability Comes Down to People and How to Improve It

Cloud outages are usually described as technical failures. When a service goes down, a dependency breaks, or a region has issues, the focus immediately shifts to infrastructure. But if you look closely at how these incidents actually unfold, the root cause is rarely the technology itself. It is almost always tied to decisions made earlier, during design, implementation, or day-to-day operations. The system behaves the way it was built. The real question is how it was built ...

Why IT Keeps Getting Handed an AI Training Problem It Can't Solve Alone

77% of leaders say their teams need AI skills urgently. 64% say their organization plans to train current employees rather than hire new ones. So far, so reasonable. The part that surprised me is who's been put in charge: 34% of those leaders say IT and engineering own the AI skills mandate. Learning and Development or HR own it at 7% of organizations. That's roughly five-to-one in favor of the people who understand the tools, over the people whose actual job is teaching adults how to learn new ones ...

Bringing IBM i Into the Modern Observability Stack: The Missing Piece of Enterprise AIOps

In the ever-evolving digital landscape, enterprises are increasingly focused on enhancing their observability stacks to gain deeper insights into their IT environments. Observability has become a cornerstone of modern IT operations, enabling organizations to monitor, diagnose, and optimize their systems with unprecedented precision. However, a critical piece of the puzzle often goes unnoticed in this transformation: IBM i ...

What Is Real User Monitoring in an Observability World? It Is Not APM "Agents" - Part 1

Eric Futoran
Embrace
Learn more about Embrace

Agent-based approaches to real user monitoring (RUM) simply do not work. If you are pitched to install an "agent" in your mobile or web environments, you should run for the hills. The world is now all about end-users. This paradigm of focusing on the end-user was simply not true a few years ago, as backend metrics generally revolved around uptime, SLAs, latency, and the like. DevOps teams always pitched and presented the metrics they thought were the most correlated to the end-user experience. But let's be blunt: Unless there was an egregious fire, the correlated metrics were super loose or entirely false. Instead, your teams should prioritize alerts, monitoring, and work based on impact to the end-user, as it directly affects your businesses. And your developers and DevOps teams should collect data, monitor, prioritize, and resolve issues accordingly.

The agent-based RUM problem

"Agents" are a mechanism that does not work in the current end-user centric world. They were born out of shimmying the principles of the backend to mobile, web, and the myriad of other ways users interact with the world. Let's compare the difference between user environments and backend environments: ■ User environments are open, unstructured, and uncontrollable as they are unowned devices and browsers with the central figure being an unpredictable user. ■ Backend environments are closed, structured, and controlled as they are composed of relatively homogenous physical and cloud applications. With closed systems that have fewer external variables, agents focus on a known set of errors to monitor and to trigger data collection for resolution. However, monitoring systems outside of the backend is complex because there are a multitude of types of errors way beyond crashes, error logs, network traces, and API errors. In an observability world, real user monitoring is about collecting "all" the data for every session — good or bad — and not just a sampled set based on predefined error types. Only by collecting the entirety of every session can the best vendors have the opportunity to analyze and provide the utmost value to your teams. These vendors have evolved beyond agents to surface every type of user-impacting issue, help resolve them by comparing against good sessions, and prioritize overall impact across the complete set of issue types. For example, the same crash for two different users could have different root causes because of the environments, third-party SDKs, and API timeout parameters. To hit the difference home, watch a developer, outside of DevOps, open a RUM dashboard for a vendor who uses the agent-based approach. The core dashboard will have the following: ■ A geographical map laying out the incidents ■ A generic list of error logs and crashes ■ Some sort of mapping of network errors ■ A single health score The developer reviewing this dashboard will not come back to it regularly or at all. And it's not hard to see why. The dashboard does not tell them which users are affected, where to prioritize their efforts, or the types of bugs and optimizations that they should care most about. It's not built for them from the data collected to data organization and display. There is a reason why these developers always implement and use other vendors — even for simple concepts like error logging and crashes — alongside those application performance monitoring vendors. Let's deep dive into the core differences between these approaches and explore what a true real user monitoring methodology looks like. That way, you will know it when you see it and can create the best experience for your end-users as well as your developers and DevOps team.

The spider web problem

To illustrate the core implication of an agent mentality, let's focus on the "spider webs." You know the ones I'm talking about. You've seen the cool demos with a picture connecting nodes across your systems to demonstrate "visibility" across all the apps running on your servers and machines. Everything is connected by an ever-expanding spider web of nodes and lines — every app, compute instance, API call, etc. Oh, it's very pretty to see all the apps and API calls going to and from each other. It's also a nice source of confidence that the agents are collecting the data required to monitor, identify, and resolve potential issues. However, the very nature of this mental model of a spider web is it assumes all the issues occur on the lines between the nodes or on the nodes themselves: ■ An increase in network latency means you should look at the connected database, server, or service calls. ■ An increase in downtime means you should look at the connected servers to see if they're under heavy load. ■ An increase in transaction failures means you should look at the connected service calls for a point of failure. The paradigm of agents is one of looking for a closed set of known symptoms for broken apps, failing processes, and poorly designed code. To help resolve these symptoms, the agents collect samples of app and process information, so that when an API throws an error or a process has downtime, the agent collects the corresponding data in reaction to the error. And this approach works … on the backend, for a known set of errors, in a controlled environment, with little external pressure from the outside world. But when applied to the client side of web and mobile, what happens when the complexity explodes?  What happens when there are an infinite number of unknown pressures, from the users, the devices, the operating systems, the app versions, the network connectivities, and the other apps running? How do you truly understand your team's effectiveness when the biggest issues are not related to downtime or following individual service calls throughout a distributed system?

The problem with uncontrolled environments

Uncontrolled environments are any digital experience that's external to data centers. Beyond just smartphones and web browsers, they're point of sales, VR and AR devices, tablets in the field, and smart cars. And the world is increasingly one of uncontrolled environments for business-critical touchpoints. The most effective developer and DevOps teams monitor these client-side environments with early warning systems to determine when users are impacted so they can triage and resolve issues. They flip the traditional application monitoring paradigm. ■ Traditional application monitoring: Sample data by looking for a known set of errors, then gather context around them. ■ Modern application monitoring: Gather data without knowing its full value, correlate those data points to user impact from the end-user vantage point, then determine the error, measure the impact in order to prioritize it, and route it accordingly. In order to collect, identify, and resolve errors correctly, DevOps teams must understand the challenges that come along with running apps in these types of uncontrolled environments. After all, the assumptions about where failure points can happen are vastly different. Start with: What Is Real User Monitoring in an Observability World? It Is Not APM "Agents" - Part 2

Eric Futoran is CEO of Embrace

Related Links

Hot Topics

Related Vendors

The Latest

AI is Moving Fast, and Enterprise File Data Is Not Ready

Pilots are everywhere, stakeholders are seeking results, businesses are pushing for new tools, and IT teams are being asked to make AI secure, reliable, and useful at scale. But as organizations move from testing AI to operationalizing it, many are discovering that the biggest barrier is not the model, the use case, or even the budget. It is the file data foundation within ...

Move Fast Without the Usual Quality Penalty

Fast or cheap? For most of my career in engineering, speed and quality sat on opposite ends of a seesaw. The "OR" in "fast or cheap" was non-negotiable. It was expected that pushing for faster releases meant that something in quality would give way. Tightening quality controls meant the schedule slipped. Every engineering leader I know has lived some version of that tradeoff ... The seesaw is starting to level out ...

When the Observability Bill Arrives for Agentic AI

I have been building enterprise software for more than 20 years ... One thing stays true across all of it: You do not find out your foundation is wrong during the crisis. You find out when the debt comes due. For a lot of organizations, that bill is arriving now. New research ... puts hard numbers on something practitioners have been sensing for a while. The telemetry problem isn't coming. It's already here ...

AI is Breaking Enterprise Log Management

The rapid growth of AI workloads is pushing traditional log management approaches to their limits, according to The State of Log Management 2026 report from Dynatrace. Modern logs have become critical to understanding, validating, and securing AI-driven decisions, helping organizations ensure reliability, compliance, and performance at scale. However, the volume and complexity of AI telemetry are overwhelming legacy tools ...

How Edge Intelligence Will Redefine Secure Connectivity

For years, secure connectivity has relied on a familiar pattern: route traffic back to centralized gateways, inspect it, and then allow access. This model worked when applications lived in a handful of data centers and users were largely confined to offices. That model is now under strain. Applications are distributed across clouds, users connect from everywhere, and real-time workloads demand performance that centralized inspection points struggle to deliver. As traffic volumes grow and latency expectations shrink, routing everything through a small number of control points has become both a performance bottleneck and a resilience risk. The future of secure connectivity requires a different approach ...

Production Inference Shifts Decisively to Private Cloud

The AI experimentation phase is over, and the private cloud is where enterprise AI workloads are being deployed for security and scale, according to Private Cloud Outlook 2026, a new report from Broadcom ... 2026 marks an acceleration into a full AI tipping point. The shift is being shaped by three forces — costs, complexity, and control — that public cloud environments are increasingly failing to address for production AI at scale. Key findings from the report include ...

Why DevOps Teams Build GenAI Tooling While Most Organizations Still Rely on Manual Monitoring

44% of organizations have reported an outage in the past year tied to suppressed or ignored alerts, and 78% had at least one incident where no alert was fired at all ... Engineers learned about failures from customers. That gap between what our tools report and what our customers experience is the problem DevOps teams have been quietly solving with GenAI tooling, even as most enterprises continue to run their NOCs on manual alert triage ...

Why Cloud Reliability Comes Down to People and How to Improve It

Cloud outages are usually described as technical failures. When a service goes down, a dependency breaks, or a region has issues, the focus immediately shifts to infrastructure. But if you look closely at how these incidents actually unfold, the root cause is rarely the technology itself. It is almost always tied to decisions made earlier, during design, implementation, or day-to-day operations. The system behaves the way it was built. The real question is how it was built ...

Why IT Keeps Getting Handed an AI Training Problem It Can't Solve Alone

77% of leaders say their teams need AI skills urgently. 64% say their organization plans to train current employees rather than hire new ones. So far, so reasonable. The part that surprised me is who's been put in charge: 34% of those leaders say IT and engineering own the AI skills mandate. Learning and Development or HR own it at 7% of organizations. That's roughly five-to-one in favor of the people who understand the tools, over the people whose actual job is teaching adults how to learn new ones ...

Bringing IBM i Into the Modern Observability Stack: The Missing Piece of Enterprise AIOps

In the ever-evolving digital landscape, enterprises are increasingly focused on enhancing their observability stacks to gain deeper insights into their IT environments. Observability has become a cornerstone of modern IT operations, enabling organizations to monitor, diagnose, and optimize their systems with unprecedented precision. However, a critical piece of the puzzle often goes unnoticed in this transformation: IBM i ...