RUM Data Explorer

This guide explains what you see in the RUM Data Explorer and how to use every panel to answer performance and reliability questions.

Performance Monitor

The Performance Monitor is your birds‑eye view across Core Web Vitals, errors, releases, APIs, and traffic. Use the time range picker and the search/filter bar (name, tag, label, annotation) to scope data. From here, you can drill into specific tabs: Overview, Performance, Errors, Deployments, and API.

1. Overview

What you’re seeing

• Broken Links: Count of navigations returning 4xx/5xx. Click to list the affected pages so you can fix stale routes and sitemap issues.
• Core Web Vitals: Current health status for:
  • FCP (First Contentful Paint): Time until the first content renders. The screenshot shows a Good value (~1.0–1.5s). Aim <1.8s.
  • LCP (Largest Contentful Paint): Loading of the main content. Shown as Good (~1.6–1.8s). Aim <2.5s.
  • INP (Interaction to Next Paint): Responsiveness after user input. Shown Good (tens of ms). Aim <200ms.
  • CLS (Cumulative Layout Shift): Visual stability. Shown Good (~0.06). Aim <0.1.
• Active Deployments: Number of versions currently observed by RUM.
• Last Seen: Recency of the latest event ingested (helps catch data pipeline issues).
• Errors & Deployments charts: Quick trendlines for total errors by version and error rate by version to spot regressions.
• User Analytics: Session and page coverage to understand traffic volume and breadth.

How to use it

• If a web vital drifts into yellow/red, pivot to Performance to see which page or third‑party caused it.
• If error rate spikes, jump to Errors or Deployments to see which release/route regressed.

2. Performance

Key panels

• XHR & Fetch Calls table: Top network endpoints with Count, Load Time, and Size. Example endpoints include analytics and session‑replay providers (e.g., https://api.factors.ai/..., https://k.clarity.ms/collect). Use it to:
  • Spot slow APIs (long Load Time) and chatty scripts (high Count).
  • Flag third‑party bloat to defer, lazy‑load, or move to workers.
• No. of Page Views & Loading Time: Distribution of page loads over time; verify if spikes coincide with latency increases.
• Count & Duration of API Calls: Shows concurrency bursts; use to size backends or rate‑limit.
• Largest Contentful Paint (time‑series): Track spikes per minute to correlate with deployments or CDN changes.
• Interaction to Next Paint (time‑series): Catch input jank from long tasks or main‑thread contention.
• Cumulative Layout Shift (time‑series): See when layout jumps occur; often due to image/video dimensions or late‑loading fonts.
• Performance of Popular Pages: Per‑view p75 LCP/INP/CLS; prioritize pages with traffic and poor p75.
• Performance Impact of 3rd‑party Resources: Posts (e.g., cdn-cookieyes.com, www.googletagmanager.com, cdnjs.middleware.io) with counts and load time.
• Long Tasks' Impact on Views: Time spent in tasks >50ms; reduce main-thread work (split bundles, code-split, avoid synchronous JS).

Practical actions

• Budget 3rd‑party scripts; defer non‑critical trackers.
• Fix CLS by adding width/height to media and reserving space for ads/widgets.
• Use rel=preload for critical LCP assets and serve images in next‑gen formats.

3. Errors (Performance View)

What’s here

• Total Errors by Version and Total Error Rate: Is a specific release noisier?
• Code Error Count vs Network Error Count: Quickly separate JS/runtime exceptions from HTTP failures.
• Views with Highest Error Rate: Routes/files with ~100% failure.
• Errors by Number of Impacted Sessions: The errors that users actually experience.
• Network Errors by Number of Impacted Sessions: Affected sessions for key docs/website routes.

How to use it

• Triage by Impacted Sessions first, then by Error Rate.
• Click a row to open Error Details and navigate to the exact sessions.

4. Deployments

Panels

• Total User Sessions by Version: Adoption curve for each version.
• Error Rate by Version: Catch regressions immediately after rollout.
• Deployments table: Cach App Version (e.g., 1.0.0_{build}_website / _docs) with Sessions, Error Rate, and Loading Time.

Release‑readiness checklist

1. New version shows traffic? ✔️
2. Error rate stable vs prior? ✔️
3. Loading Time is not worse? ✔️

If any answer is no, drill into Errors and Performance of Popular Pages for that version.

5. API (Resources)

Use this to answer: What assets/API calls are slow or heavy?

• Slowest Resources: Top offenders by latency (e.g., large JS chunks or images).
• Heaviest Resources: Biggest bytes on the wire (optimize or lazy‑load).
• Total Resources: Volume of unique assets requested.
• Resource Load Time (Median & P90) and DNS Lookup Duration (P90): Shows network‑level hotspots.
• Time to First Byte (Median & P90): Detect origin or CDN regressions.

Fix patterns

• Compress and resize heavy images; prefer AVIF/WebP.
• Split JS chunks; avoid unused polyfills.
• Push/Preload critical CSS; ensure CDN caching works.

Session Explorer

What you’re seeing

• Session Trend: Minute‑by‑minute sessions to understand traffic patterns.
• Session table with columns:
  • Time Created / Last Updated: Session lifecycle.
  • Visitor Info: Country flag and device/browser/os icons.
  • Trace Time Spent: Total time observed in backend traces related to the session (helps correlate front‑end time with backend work).
  • Visitor: Anonymized by default.
  • Action Count: Number of significant interactions captured.

Open any session to access the player and developer panes:

1. Events Tab

• Event stream with Duration, Name, and Type (e.g., Fetch/XHR). Useful to:
  • Align user actions with network calls and UI updates.
  • Pinpoint the exact moment a slow API/UI event occurs.

2. Network Tab

• Per‑request details: Status, Method, and Type (Fetch/XHR). Quickly spot failed calls (non‑2xx) and retries.
• Session Player: Pixel‑accurate replay alongside a timestamped Console.
• Console filters: Info/Debug/Warn/Error (the example shows several Error on LINK/SCRIPT). Toggle Wrap Text and Auto Scroll when reproducing issues.
• Skip Inactive mode: Jump across periods of user activity to speed up triage.

Workflow Tips

1. Reproduce: watch the replay at the timeline where the console shows an error.
2. Inspect: switch between Events and Network to confirm if the error mapped to an HTTP failure.
3. Correlate: open the related trace/log (when linked from the session) to see backend latency and errors.

Error Tracking

Panel Anatomy

• Errors Trend — total error count over time; hover to see the timestamp and value.
• Errors table with columns:
  • Name — normalized error signature (e.g., HTTP GET https://middleware.io/_next/data/{buildId}/index.json).
  • Error Type — fetch/xhr/code etc.
  • Instances — occurrences.
  • Last/First Occurrence — recency windows.
  • Affected Users — prioritization by user impact.

How to use it

• Sort by Affected Users to prioritize customer‑visible defects.
• Open an error to view Error Details (section 1.6) and jump into impacted sessions.
• Use the global filter/search to narrow by team tags, labels, or annotations.

Error Details (drill‑down)

Header KPIs

• Affected Users: Unique users hit.
• Instances: Occurrences across sessions.
• Last/First Occurrence: Time since last/first seen.
• Errors Over Time: Sparkline/timeline to spot bursts.

Session Details

• General: Project Name, Event Type = fetch, Type = fetch.
• Env: prod (example).
• Method/Status: e.g., GET 404 (indicates missing resource).
• Geo & Device: Country/continent, desktop/mobile, OS, browser.
• HTTP: Scheme, host, masked Root URL (e.g., /blog/{slug}/).
• Telemetry: SDK name/language/version (e.g., opentelemetry, webjs), useful for SDK upgrades.
• Error block: Normalized error name/type/object when provided.

What to do with a 404 on /_next/data/{buildId}/index.json

• Verify static generation for the route; ensure {buildId} and page data exist post‑deploy.
• Confirm rewrites/redirects for / and /blog/{slug} are correct.
• Check CDN purge strategy so stale {buildId} links don’t linger.

Putting it together

• Release regression: In Deployments, find the new version with a rising Error Rate → open Errors to locate the failing route → Error Details reveals Status=404 and Root URL /blog/{slug} → jump into a related session to watch the failure and confirm the bad link → fix build routing; purge CDN.
• Slow page interaction: Performance shows a spike in INP and Long Tasks → check 3rd‑party Impact for heavy scripts → in the Session Explorer, the Console shows Error on SCRIPT near the spike → defer that script and re‑measure.
• Heavy asset: API/Resources lists a large image/JS bundle → compress/split and verify P90 Resource Load drops.