Translated from the Korean original. Some screenshots show the original Korean interface.
Why do customers say it's slow when the metrics look fine?
This happens all the time in operations. Average response time and error rate on the dashboard are within normal range, yet the customer support desk and business teams report that the service is "slow" or "freezes now and then." The reverse also happens: intermittent incident alerts fire, but real users notice nothing.
The gap comes from a difference in perspective.
- Customers judge by the speed and stability they experience directly in a browser or mobile app.
- Operators judge performance by internal metrics from servers, applications, and databases.
To understand performance properly, you need both perspectives.
- RUM (Real User Monitoring): collects the experience real users actually have
- APM (Application Performance Monitoring): traces how the application behaves internally and what causes performance bottlenecks
In this post, I show how to use RUM and APM together to find bottlenecks hidden behind averages, shorten incident recovery time, and improve customer satisfaction at the same time.
1. What is RUM? Definition and how real user monitoring measures performance
RUM is a monitoring method that collects key performance data from real users' browsers and mobile apps. Unlike server-side monitoring, it directly measures what users experience: page load time, rendering speed, interaction delay, and more.
It is especially good at finding variance hidden behind averages and problems that appear only under certain conditions. For example, even if the overall average response time is 2 seconds, RUM can catch a problem where a certain region or device takes 10 seconds. These are important metrics that directly affect user satisfaction and bounce rate.
1-1. Key performance metrics RUM measures
To quantify the real user experience, RUM collects metrics like these:
- Network performance: DNS lookup, TCP connection, TLS handshake, request-response transfer time
- Loading/rendering performance: Core Web Vitals (LCP, INP, CLS), First Contentful Paint (FCP), DOMContentLoaded, Time to Interactive (TTI)
- Interaction/user behavior: click and scroll responsiveness, AJAX response time, JavaScript error rate, response patterns per session
- Segmentation: by browser, OS, and device; by region and network (carrier/corporate network); by user group
1-2. 4 situations where you need RUM
1) When performance degrades only with a specific combination of browser, OS, and extensions
→ Find client-side environment problems that server metrics cannot catch
2) When a localized problem occurs only in a specific region or network
→ Accurately diagnose CDN configuration issues, network routing errors, and similar problems
3) When you need to measure the performance of key user journeys such as login, search, and checkout
→ Understand the perceived performance of key features that directly affect the business
4) When you suspect performance degradation or a rise in bounce rate after a new release
→ Analyze performance regressions by comparing before and after the release
[Practical tip]
Synthetic monitoring uses virtual users that automatically and repeatedly run key business flows to catch problems before real users arrive. It is even more effective when combined with RUM.
Synthetic monitoring detects problems in advance, and RUM confirms the impact on real users. Together they form a double safety net.
2. What is APM? Core capabilities of application performance monitoring
APM is a performance management solution that traces an application's internal behavior in detail, down to transactions, code, databases, and system resources. It records and analyzes every step, at millisecond granularity, from the moment a user request reaches the server until the response is produced.
It precisely measures the latency in each API call, database query, and external service integration to identify bottlenecks. The core goal is to find the root cause of incidents and performance degradation quickly. This shortens MTTR (mean time to recovery) and improves service availability.
2-1. Key APM capabilities
- Transaction tracing and distributed tracing: visualize the full path a request takes (service → module → external call) to locate bottlenecks
- Code-level analysis: analyze slow methods, synchronization issues, external API call delays, and more at the code level
- Database analysis: detect slow queries, missing indexes, connection pool shortages, and lock contention
- System resource monitoring: track CPU, memory, thread pools, GC (garbage collection), and I/O utilization
- Error tracking: identify where exceptions occur, their types, and their impact to prevent recurrence
2-2. 3 situations where you need APM
1) When you need to pinpoint the cause of an incident or slowdown and recover quickly
→ Shorter MTTR and root cause analysis
2) When you need to fix recurring bottlenecks at the root
→ Code improvements, query optimization, resource allocation tuning
3) When you need to monitor SLA/SLO violations and put measures in place to prevent recurrence
→ Meet performance targets and assure service quality
3. RUM vs. APM: What to use and when
Aspect | RUM (user view) | APM (system view) |
Focus | Perceived performance in the browser/app | Internal performance of transactions, code, DB, and resources |
Metrics | FCP, TTI, full page load, AJAX/HTTP, session errors and responses | Response time, error rate, slow queries, external calls, threads/resources |
Strength | Makes per-segment variance and conditional issues visible | Provides root cause analysis and evidence for structural improvements |
Limitation | Limited ability to identify causes | Limited view of UX and per-environment variance |
Perspective | "What happened?" (symptom, user experience) | "Why did it happen?" (cause, internal behavior) |
RUM and APM are complementary tools that analyze the system from different perspectives.
Combined, they give you full observability into both "what happened" and "why it happened."
[Key point]
Use RUM for symptoms and APM for causes.
Using the two together shortens the time it takes to solve problems.
4. RUM and APM in practice: How real problems get solved
Case 1. Login is slow only in a certain region
One day, the customer support desk is flooded with complaints: "Login is really slow when I connect on mobile in the Seoul metropolitan area."
- What RUM found: login time for users on LTE networks in the Seoul metropolitan area rose to more than 3 seconds on average
- What APM confirmed: backend servers were healthy, but communication with an external authentication service was delayed on one specific network path
- Fix: change network routing, cache authentication data, adjust timeouts
→ RUM found "where" the problem was, and APM revealed "why."
Case 2. Average metrics look fine, but user complaints keep growing
Average response time on the monitoring dashboard is normal, yet complaints from certain users keep coming.
- What RUM found: Time to Interactive (TTI) spiked to more than 10 seconds with Safari plus a specific ad-blocking extension
- What APM confirmed: servers and DB were all healthy. The frontend bundle size and third-party scripts were the likely cause
- Fix: JavaScript code splitting, image optimization, removing unnecessary third-party scripts
→ Don't look only at averages. Look closely at the problems users under specific conditions run into.
Case 3. Payments fail after a new release
After an emergency release on Friday evening, the payment failure rate surged all weekend.
- What RUM found: right after the release, first render (FCP) and Time to Interactive (TTI) on the checkout page got worse, and bounce rate on older Android devices rose by 50%
- What APM confirmed: newly added payment verification logic called an external payment gateway API synchronously, causing intermittent timeouts
- Fix: switch to asynchronous processing, apply the circuit breaker pattern, cache part of the payment data
→ Tracking performance changes before and after a release lets you find the cause quickly.
[3 principles to remember in practice]
1. "Averages lie"
Even when the overall average is normal, customers on certain browsers, regions, or devices may be having serious problems.
2. "See symptoms and causes with different tools"
Accurate diagnosis requires looking at both what users experience (RUM) and what is happening inside the system (APM).
3. "Unified monitoring is the new standard"
The days of guessing while jumping between tools are over. Connect RUM and APM on a single platform.
5. Checklist before adopting monitoring
We have looked at how RUM and APM are used in practice.
Before choosing the right combination for your organization, first check whether you are ready to adopt it.
Step 1: Clarify business requirements
We have defined our key user journeys. (e.g., login → search → checkout)
We know the biggest problem we are facing right now (e.g., customer complaints, slow incident response, performance degradation)
We have a specific goal we want monitoring to achieve. (e.g., cut MTTR by 50%)
We can quantify the business impact of an incident. (e.g., revenue, customer churn)
Step 2: Check technical infrastructure
We have documented the architecture of the systems to be monitored.
We have access to the frontend and backend code.
We have an established deployment process.
We have a system for log collection and retention.
Step 3: Organization and operations
A person or team responsible for monitoring has been assigned.
We have a reporting and response process for incidents.
We can convince managers and decision-makers.
We have secured the budget needed for initial adoption.
💡 How to read your results:
✅ 10 or more: You're all set. Start adopting RUM + APM together now.
⚠️ 7-9: You're ready to adopt. Start with either APM or RUM, fill in the gaps, and expand gradually.
🔍 5-6: You need a bit more preparation. Start by defining key journeys and assigning an owner.
❌ 4 or fewer: Clarifying business requirements comes first. Build consensus in your organization, then consider adoption.
Once you've gone through the checklist, choose the combination that fits your organization.
6. Choosing the right monitoring combination for your organization
Option | Best for | Pros | Risks/Mitigation |
APM only | - Environments where backend bottlenecks dominate
- Early adoption stage | - Strong root cause analysis
- Fast problem resolution | Hard to know what real users experience
→ Adding RUM for key pages is recommended |
APM + basic RUM | - Focus on key pages only
- Limited budget
- Small operations staff | - Cost-effective
- Early detection of user-facing issues
- Low complexity | Limited for detailed UX analysis
→ Supplement with synthetic monitoring |
APM + full RUM
(+ synthetic monitoring) | - Services with complex frontends
- Large-scale B2C services
- Bounce rate directly tied to revenue | - Best proactive detection
- See experience and cause at once
- Full visibility | Higher adoption/operating cost
→ Expand in stages |
[Selection guide]
For most companies, starting with "APM + basic RUM" is the realistic choice.
- First, stabilize the backend with APM. (3-6 months)
- Apply RUM to your 2-3 most important pages and verify the effect.
- Once the value is proven, expand gradually.
For Korean companies in particular:
- If mobile apps make up a large share → prioritize mobile APM/RUM
- If you are in finance/commerce → RUM on payment pages is a must
- If you are B2B-focused → focus on maturing APM first
7. A unified monitoring strategy starting with exemONE
As we have seen, RUM shows where, when, and during what action users feel things are slow, and APM tells you whether the reason lies in code, queries, or infrastructure.
The problem is that looking at them separately slows down your response. A typical example is when averages look normal but conversion drops only on a specific browser or path. In that case, you can find the cause quickly only if the clues left in the user journey connect seamlessly to backend trace data.
exemONE lets you do all of this in one place. You can jump straight from user behavior and performance metrics (RUM) to backend traces (APM), and see infrastructure, K8s, application, and DB logs on a single screen. You spend less time guessing while switching screens, and fewer interpretation gaps arise when handing issues between people. As a result, the cycle from detection to analysis to action gets shorter, and the path to preventing recurrence becomes clear.
With exemONE, start with your most important transactions, then gradually expand to all pages, logs, and DB as needed. After adopting exemONE, you can verify the changes quantitatively through unified monitoring and composite alerts and reports, and use that to improve operational quality systematically.
Going forward, analyzing the entire path end to end on a single platform will become the standard for stable operations.
8. FAQ: 5 questions we often hear from operations teams
Q1. Why do customers say it's slow when the average response time is normal?
An average does not show the full picture. For example, if 95 out of 100 users see the page in 1 second but 5 wait 10 seconds, the average comes out at about 1.5 seconds, which looks "fine." But those 5 users are having a very poor experience. Server-side APM shows only the average backend response time, so it is hard to spot problems affecting a particular group of users like this.
With RUM, breaking the data down by browser, OS, region, and network makes these hidden problems clearly visible.
Q2. What is the difference between synthetic monitoring and RUM?
Synthetic monitoring uses automated scripts that visit the site periodically along predefined scenarios to measure performance. For example, every 5 minutes a script runs login → product search → add to cart and checks the response time of each step. Its advantage is catching problems before real users arrive.
RUM measures the performance real customers experience as they use the site. Because it collects data from real users' browsers, it shows reality as it is.
The two serve different purposes, so using them together works best. We recommend dual monitoring: detect issues in advance with synthetic monitoring, and confirm real impact with RUM.
Q3. Where should we start with monitoring?
Start with the journeys that matter most to the business. For most services, those are login, checkout, and search.
For these key features, it is important to apply both RUM and APM so you monitor user experience and system performance at the same time, and to set alerts in detail by segment, such as by browser or region, rather than on the overall average.
Q4. How do we monitor mobile apps?
Mobile apps behave differently from the web, so they need dedicated tools. App crashes, dropped connections when switching from WiFi to LTE, battery usage, and similar issues are hard to catch with regular web monitoring.
By observing the real user experience with mobile-specific RUM and the app's internal behavior with mobile APM (e.g., InterMax for mobile) at the same time, you can monitor without blind spots.
Q5. Can we get value from monitoring on a limited budget?
Absolutely. You don't need to adopt everything at once. We recommend a step-by-step approach.
1) Stabilize the backend with APM (3-6 months)
Fixing root problems in servers and DB improves a large part of perceived performance.
2) Add RUM to key pages
Applying RUM to just your 2-3 most important pages (login, checkout, etc.) is enough to understand user-facing issues.
3) Expand after verifying the effect
Once the data proves the value, gradually widen the scope.
[Practical tip]
exemONE is built for this kind of gradual expansion strategy.
You can start with core features and expand step by step according to your budget and needs, so you can build an effective monitoring environment even on a limited budget.
Related articles
