A severity-based heatmap in Motadata ObserveOps that colors Core Web Vitals render milestones from real browser sessions, so frontend health reads at a glance.
A wall of session numbers rarely tells you where a web application is hurting. The RUM Flame Chart in Motadata ObserveOps, a severity-based heatmap over frontend counters, converts real measurements into a color view, so the pages that need attention stand out without reading a single table of numbers.
The Flame Chart works over the data the RUM module already collects from real browser sessions across Vue.js, Angular, React, and Next.js applications. Because it draws on existing telemetry, it needs no extra instrumentation or configuration to switch on. You point it at the counters you care about and read the color, not the columns.
Introduced in the release alongside a set of RUM Policy View enhancements, the Flame Chart is a widget in the platform's unified dashboard builder. RUM contributes two counters to it: Largest Contentful Paint and First Contentful Paint, the render milestones from Core Web Vitals that shape how fast a page feels. The same widget reads response time and error rate from Application Performance Monitoring when that module is active, so frontend and backend teams share one visual language for severity even though each team reads its own layer of the request: RUM's counters cover what happened in the browser, and APM's cover the backend service data it owns.
This severity view is distinct from RUM's frontend flame charts, which lay out a single session's rendering timeline. The Flame Chart on this page reads severity across many sessions; the rendering flame chart explains one page load from the inside.
The Flame Chart renders Largest Contentful Paint and First Contentful Paint by severity, so the page-quality signals real visitors feel are visible in one place.
Each cell is shaded by severity, which turns a range of raw values into a fast visual read of what is healthy and what is degrading.
The Flame Chart uses the browser data RUM already collects, so no additional telemetry configuration is required to start visualizing severity.
The color view reflects current session data, so a slowing render milestone shows up as it develops rather than after the fact.
The same widget reads backend counters from Application Performance Monitoring, giving frontend and backend teams a consistent way to read severity across the platform.
Also from the release, severity color indicators now appear directly on RUM policy records, so a policy list reads its own health at a glance rather than requiring a separate severity view.
Business Service associations are surfaced in the RUM policy list, so a severity signal reads against the named service it affects rather than as an isolated policy entry.
The alert heatmap now supports RUM grouping, so RUM-triggered alerts can be read by severity alongside alerts from other policy types instead of in a separate view.
A Flame-Chart-driven investigation, its filters, counters, and time range, can be preserved through Saved Views in Session Explorer, so a recurring severity check is one click away.
Severity color replaces number-hunting, so a degrading page draws the eye before anyone opens a report.
Reading render milestones as color lets a team decide what to look at first without parsing individual session records.
Because no extra telemetry configuration is required, the Flame Chart is usable on day one over the sessions RUM is already capturing.
With the same widget co-available in APM, frontend and backend groups discuss severity in the same terms instead of translating between tools.
Watching Largest Contentful Paint and First Contentful Paint by severity keeps attention on the render milestones that shape how fast a page feels to real users.
Business Service associations in the RUM policy list mean a severity signal points at the service it affects, so triage starts with a name instead of a policy ID.
The RUM module instruments the browser and collects session data directly from real users across Vue.js, Angular, React, and Next.js applications, including the Largest Contentful Paint and First Contentful Paint signals the Flame Chart reads. No additional telemetry configuration is needed beyond the standard RUM data collection.
Collected values are assessed by severity across the supported counters, so each measurement is placed on a scale from healthy to critical rather than left as a bare number. The same severity model extends to RUM policy records, where Business Service associations and RUM grouping in the alert heatmap add context to a triggered alert.
The severity assessment is rendered as a color view on the dashboard. Cells shift shade as conditions change, giving a real-time visual read of frontend health. A Flame-Chart-driven view can be preserved through Saved Views for reuse, and backend request analysis stays with Application Performance Monitoring, which reads its own counters in the same widget so severity reads consistently across both. See Application Performance Monitoring for the backend view.
The Flame Chart does not depend on which of the four supported frameworks generated a session. A Vue.js page, an Angular route, a React component, and a Next.js render all report the same Largest Contentful Paint and First Contentful Paint signals, so the color view stays consistent across a portfolio that mixes frameworks. Because the Flame Chart draws on session data RUM already collects rather than a separate probe, adding a new framework to your web estate does not require a separate configuration; the moment RUM instruments the application, its sessions read into the same severity view.
Sharing one widget does not mean sharing one dataset. RUM contributes the frontend counters the module collects from the browser: the Largest Contentful Paint and First Contentful Paint render milestones a real visitor experienced. APM contributes the backend counters it records from its own Application Performance Monitoring instrumentation: service response time and error rate on the server side, gated by the APM module's own license.
That shared visual language is deliberate. It lets a frontend team and a backend team describe how bad a problem is in the same color scale, even while each team reads a dataset that belongs to a different module.
The RUM Flame Chart gives Motadata ObserveOps users a direct, visual route to frontend health across every supported framework. By coloring Largest Contentful Paint and First Contentful Paint by severity over data the browser sessions already provide, and by carrying that same severity model into policy records and Saved Views, it turns monitoring from a reading exercise into a glance. For teams that also run Application Performance Monitoring, it is a shared severity view that keeps the frontend and backend conversation in step.
Discover how Motadata ObserveOps can help you monitor your infrastructure in real-time and respond to issues instantly.