Between October 25 and November 8, RUM changed one thing each in dashboards, error grouping, and query, and gained a new kind of context on the collection side.
A dashboard belongs to one application
A custom dashboard now belongs to the application it was created in, and every panel's query reads that application only, so the panel editor drops its application picker: the old Page application option ($app, resolved to the page's current application) survives only in definitions saved before this change.
The Insights tab bar lists the current application's dashboards (by title, up to 100), and Manage dashboards lists every application's. Opening another application's dashboard from the manage page or a link first switches the page to the application it belongs to, then opens it. Switching the application by hand on a dashboard tab leaves that dashboard and returns to the Overview tab, which belongs to the new application. A copy of another application's dashboard stays in that application. Dashboards saved before this change take the application of their first query that reads a concrete one; an old dashboard that reads no concrete application no longer appears in the application's tabs and can no longer be edited, so create it again under its application.
Exact queries per chart, and granularity on the trend chart
With a large amount of data, a Sampled mark appears next to a chart's title. Click it to run that chart once over all data. An account can run 2 exact queries at once by default. The User Access Trend chart on the overview page gains a Granularity dropdown (5 min, 1 hour, 1 day; 1 hour by default) and a Per interval / Cumulative switch.
Errors split by where they were raised
The same error message raised from two different places in the code now makes two Issues instead of one. The location is taken from what survives a rebuild: for a Web JS error, the script and function of its top meaningful stack frame; for Android, the throw site of the exception chain's root cause plus the first app-code frame below it; for an iOS crash, the crash site plus the first app-code frame below it. Line and column numbers, build hashes, and minified or obfuscated names take no part, so a new release does not split one bug into new Issues.
A minified frame that cannot be told apart is not used as a location, and such errors keep grouping by type and message. An iOS frame the SDK could not resolve can only be told apart by its offset inside the image, and that offset is stable within one build only, so such a crash can become a new Issue after every release — uploading dSYMs changes how the stack reads in the console, not how it is grouped. Existing browser and Android Issues keep receiving their message from every location, with their status, assignee, and history; iOS crashes do not carry over to the old signal-only Issue and start anew by crash location. A custom fingerprint still takes precedence.
Natural-language query for native apps
Basic natural-language query now reads your question against the current application's platform. For Android, iOS, HarmonyOS, Flutter, and React Native apps you can ask about crashes, ANR, App Hang, jank, OS version, and device model.
Response headers and request bodies on resource events
In the Web SDK's beforeSend, both Fetch and XHR can read response headers, the status code, and the URL synchronously and write them into event.context; an XHR response body (JSON or JSON text) and a Fetch string request body can go in too. A Fetch response body can only be read asynchronously, and beforeSend does not wait, so it is not supported. The whole event.context you write back has a default budget of 225,280 characters — past it, the SDK stops copying further fields and warns in the console — and an event that reaches 256 KiB is dropped.
Get started
Go to Flashduty console → RUM. Dashboards live under Insights, and errors under Error tracking.
Product docs: RUM custom dashboards, Chart readings, Error grouping, Data query syntax guide, Web SDK advanced configuration.