Applications and Overview

Frontend (/frontend/applications, under Observe in the sidebar, marked Beta) lists your Real User Monitoring applications. Click one to open its overview.

Use these screens when you want to know how fast your pages are for real users, which JavaScript errors they hit, or which backend request was behind a slow or failing page.

All numbers follow the time range at the top right, Last 30 minutes by default.

Note

Every role can read the Frontend screens, Viewer included. Creating, editing and deleting applications, their keys and their source maps needs Admin or Editor; viewers see the settings read-only and never see keys.

The applications list

1. Count line: how many applications there are and how many sessions they had in the range.
2. New application: create one; see Set up a web application or Set up an Android application. SDK docs opens the SDK’s README.
3. KPI strip, over every application:
   • Applications, with how many are web and mobile;
   • Sessions;
   • Session error rate: the share of sessions with at least one error;
   • Good LCP: the share of page loads with an LCP of 2.5 s or less;
   • Outdated SDKs: applications whose latest data came from an SDK version this server no longer supports, or All supported.
4. Search applications by name, and filter by platform (Web or Android) and Environment.
5. Application: its name, platform and environment. Click the row to open its overview.
6. Sessions and Error rate, with the change from the previous period of the same length.
7. LCP p75, INP p75 and CLS p75, each rated Good, Needs work or Poor. See Web Vitals in plain words.
8. SDK: the SDK and version the application last reported, such as @fusescope/browser or io.fuseone.fusescope:android, and its support badge: Supported, Outdated (data is still accepted) or Other client for another OpenTelemetry SDK. Last seen shows recent activity and when the last data arrived, or No data yet.
9. Settings opens the application’s sheet: Settings, Public key, Install and Source maps, or R8 mappings for an Android application.
10. Supported SDK: the SDK this server is tested with. Any OTLP client is accepted.

Platform and allowed sources

Each application has a platform, Web or Android, chosen when you create it and fixed afterwards. iOS is shown as coming soon. The platform decides who may send data with the application’s key, which the gateway checks on every request:

Platform	Allowed	Matched against	Examples
Web	Allowed origins	the browser’s Origin header	https://shop.example.com, https://*.example.com, *
Android	Allowed package names	the app.package.name resource attribute, the app’s applicationId	com.example.shop, com.example.shop.*, *

• A wildcard entry such as com.example.shop.* matches sub-packages, such as com.example.shop.debug, never com.example.shop itself.
• An Android application refuses requests that carry an Origin header, or whose package is missing or not allowed. A web application can’t have package names, nor an Android one origins.
• Both lists are server settings: a change applies when you save, without a new app build.

The other settings, sampling, consent and privacy, are the same for both platforms; see Set up a web application and Set up an Android application.

The overview

Click an application to open its overview (/frontend/applications/<id>). Here it is narrowed to release 1.0.0:

Header

1. Badges: the platform (Web or Android), the environment and the release, which is the version your app passes to init() (on Android, the release, by default the versionName): the latest one, or the one selected in Release.
2. SDK badge: the SDK and version last seen, such as @fusescope/browser 0.2.0-beta.0 · Supported.
3. Create alert starts an alert rule from a frontend template: LCP p75, session error rate or JavaScript errors. See Frontend alerts.
4. View traces and View logs open the Traces and Logs explorers filtered to this application. RUM spans (views and requests) are traces; errors, Web Vitals and clicks are logs.
5. Settings opens the application’s sheet: Settings, Public key, Install and Source maps.
6. Tabs: this Overview, then Views (one row per route), Errors (errors grouped, with their stack traces) and Sessions (every visit, with its timeline). The release and the time range follow you from tab to tab.

Key numbers

7. Release: narrow every tab to one release, to compare a new version with the previous one.
8. Sessions, Views (with views per session) and Session error rate, the share of sessions with at least one error, each compared with the previous period of the same length.
9. LCP p75, INP p75 and CLS p75, each with its rating and a bar that splits the page loads into good (green), needs improvement (amber) and poor (red). The line under the strip says how many page loads the vitals come from, and the thresholds for good.

Note

For an Android application, the strip shows Cold start p75, Warm start p75 and Hot start p75 instead, from the app_start vital, with the same split bars. Good is below 2.5 s cold, 1 s warm and 0.75 s hot; poor from 5 s, 2 s and 1.5 s, Android vitals’ thresholds. Top routes by LCP has no vitals: LCP is a browser measure.

Panels

10. Top routes by LCP: one row per route template where pages were loaded, slowest LCP first, with the number of Page loads, LCP p75 and its split, INP p75, CLS p75 and Errors. Vitals belong to the route the page was loaded on, so a single-page app that is always entered through / shows mostly / here. All views opens the Views tab, which has every route.
11. Recent errors: errors (on Android, crashes and ANRs too) grouped by fingerprint, with the Route, the number of Events and of Sessions affected, and Last seen. Open in Logs shows all of them in the Logs explorer; All errors opens the Errors tab.
12. Click an error to open its detail, with its stack trace. View in Logs opens its events.
13. Recent sessions: the latest sessions with when they Started, their Duration, number of Views and Errors, Browser · OS (Device · OS on Android, such as Google Pixel 8 · Android 14) and Release. All sessions opens the Sessions tab.
14. Click a session to open its timeline.
15. View backend trace opens, in Trace details, the backend trace of the session’s slowest or failing request, such as GET /dispatch 200 · 759 ms. No backend requests means the session made no linked request.
16. All traces for these sessions opens the Traces explorer filtered to their session.id values.

Example: errors, and the backend behind a click

The numbers are from the shop-demo sample application. Its Order a ride button calls the HotROD demo’s /dispatch API, and two buttons raise JavaScript errors. Release 2.0.0 is a bundled build whose source maps are uploaded.

1. Open the application. In Frontend, the shop-demo row shows 22 sessions and an Error rate of 68%: more than half the visits hit an error. LCP, INP and CLS are all Good, so the pages are fast; the problem is errors.

2. Read the errors. In Recent errors, TypeError Cannot read properties of undefined (reading ‘price’) is an uncaught error, a bug in the page’s code. Error Failed to fetch: POST /api/cart returned 502 is an unhandled promise rejection.

3. See the stack trace. Click the TypeError. Its detail shows the original code when source maps are uploaded for the release, and the clicks and requests that led to it. See Errors.

4. Open the backend side of a click. Back on the overview, in Recent sessions, each row’s Backend trace shows the session’s slowest request, such as GET /dispatch 200 · 759 ms. Click View backend trace: Trace details opens the trace that started in the browser, with the browser’s request span and, under it, the spans of the HotROD services that answered it. That is where the time went.

What you learn: the pages are fast but fragile: two JavaScript errors account for the error rate, and the slowest user-facing wait is a backend call you can now read span by span.

Related

• Views, Errors and Sessions
• Set up a web application and Set up an Android application
• Keys
• Trace details