Skip to main content

Troubleshooting with Real User Monitoring (RUM)

Overview​

Frontend performance issues are rarely obvious. A page may technically load, but users still experience delays, freezes, rage clicks, or broken flows. Console logs and synthetic tests only tell part of the story—they don’t explain what real users experienced, on real browsers, under real conditions.

This is where Motadata Real User Monitoring (RUM) becomes decisive. RUM allows frontend engineers, performance teams, and product owners to move from symptoms to root cause with clarity and speed.

This page walks through a real-world RUM troubleshooting scenario, demonstrating how to identify a slow user experience, isolate the problematic view, drill into user actions, and pinpoint the exact frontend bottleneck.

Troubleshooting User Experience Using Motadata RUM​

Motadata RUM enables teams to diagnose performance issues by analyzing real user sessions instead of assumptions. In the below examples, we will investigate two cases:

  1. Where user experience high page load time in a production web application more than usual.
  2. Where user experience surge in Error count than usual.

Scenario Overview​

Once configured, from the RUM Explorer, multiple applications are visible in tile view. One application AnyTrade stands out with its key KPIs, that immediately signals a degraded user experience that needs investigation.

Step 1: Identify the Problematic Application in RUM Explorer​

In the RUM Explorer section, the tiles representing the registered applications display key metrics such as Loading Time, Error Count, LCP (Largest Contentful Paint), and Apdex Rating. Upon looking at the AnyTrade tile, you notice that the Loading Time is significantly higher than other applications.

  • Loading Time: 4.25 seconds

Click the AnyTrade tile to begin analysis.

Step 2: Analyze High-Level Experience in the Overview Tab​

Clicking the tile, you land on the Overview tab for the selected application.

This view provides an aggregated snapshot of user experience:

  • Total Sessions and Views
  • Sessions with Errors
  • Apdex Rating
  • Core Web Vitals trends
  • Page View TreeMap
  • Top N bar-chart for Views with Error count and Resources
  • Page View Performance Summary grid

Scroll down to the Page View Performance Summary grid.

This grid lists all views (pages) with their associated performance metrics.

Step 3: Isolate the Slowest View​

Sort the Loading Time (LT) column in descending order. This immediately surfaces which view contributes most to poor user experience.

In this scenario, /checkout.html appears at the top with the highest loading time.

Click the View Name to open the performance drill-down.

Step 4: Drill Into View Performance​

The performance drill-down displays detailed performance data for /checkout.html, including:

  • Loading Time
  • LCP, FCP, CLS, INP
  • Resource distribution
  • Page View Performance Summary

Go to the Page View Performance Summary section and sort again by Loading Time.

Click the timestamp with the highest loading time to open the event-level drill-down.

Step 5: Analyze the View Event Timeline​

The View Event drill-down provides:

  • Session context (browser, OS, version, environment, etc.)
  • Frustration status
  • A flame chart showing the exact sequence of events during the page load

From the flame chart, it becomes evident that a user interaction named Click on checkout is taking significantly longer time.

This indicates that the delay is not just page rendering, but an interaction-driven bottleneck.

Click the “Click on checkout” action in the flame chart.

Step 6: Investigate the Action Performance​

You are now redirected to the Performance tab in Action drill-down.

This view shows:

  • Action duration
  • Associated view and session
  • Frustration indicators
  • A detailed flame chart for the action lifecycle

The flame chart reveals a long task running during the checkout click, lasting approximately 4.2 seconds well beyond acceptable thresholds.

Click the Long Task in the flame chart to continue drilling down.

Step 7: Pinpoint the Long Task Root Cause​

The Long Task drill-down exposes what blocked the browser’s main thread.

In this case, two execution segments stand out:

  • Event Listener: 1s 800ms
  • User Callback: 1s 600ms

These tasks together account for the majority of the interaction delay.

This confirms the root cause:

Excessive JavaScript execution during the checkout interaction is blocking the main thread, causing long delays and user frustration.

Step 8: Resolution and Validation​

Armed with this insight, frontend engineers can:

  • Optimize or refactor the event listener logic
  • Defer or split long-running JavaScript tasks
  • Move heavy computation off the main thread
  • Improve interaction responsiveness (INP)

Once changes are deployed, teams can return to RUM Explorer to validate:

  • Reduced Loading Time
  • Improved INP

Key Takeaways​

CapabilityValue Delivered
Real User VisibilityTroubleshoot actual user experience instead of synthetic assumptions.
View-Level IsolationQuickly identify which page causes performance degradation.
Action-Level AnalysisPinpoint slow user interactions like clicks and navigation.
Long Task DetectionSurface JavaScript blocking issues affecting responsiveness.
Timeline CorrelationUnderstand how views, actions, resources, and scripts interact.
Faster RCAReduce mean time to resolution with precise frontend insights.