Application management

Overview

A RUM application is a container for frontend performance monitoring data, used to collect, store, and analyze real user experience data from frontend applications. An application represents a monitored frontend project, which can be a website, mobile app, or single-page application.

We recommend creating RUM applications based on business systems or applications, such as: official website, e-commerce store, admin dashboard, and so on.

Each application has its own unique applicationId and clientToken, used to identify data sources and ensure data security. After the application is created, you need to integrate the SDK into your frontend code to start data collection and monitoring.

Application permissions

To meet the data security requirements of different business scenarios, RUM applications provide flexible access level settings:

Access Level	Visibility	Applicable Scenarios
Public	Visible to all users in the account, can view data and handle Issues	General business applications
Private	Only visible to creator, account administrator, and owner account	Sensitive business data

In private applications, if other members need to view content, they can be temporarily authorized to access it by sharing the incident link.

Create application

You can quickly create an application through the RUM product guide page:

Select Application Type

Select the frontend technology type corresponding to the application, currently supporting JavaScript (JS), Android, iOS, HarmonyOS, Flutter, WeChat Mini Program, Electron, and React Native.

Set Management Team

Specify the management team for this application.

Team members have full operational permissions for this application, non-team members only have read-only access to the configuration of this application.

Configure Geo-information

By default, automatic collection of user geo-location data is enabled. To disable automatic collection of client IP or geo-location data, turn off the geo-information collection switch.See Data Collection.

Configure Alerts

By default, alert notifications are automatically enabled to facilitate timely handling of errors.See Issue Alerts.

SDK configuration

You can modify parameters and preview the initialization code in real-time in Application Configuration → SDK Configuration to quickly integrate the SDK. The console provides detailed integration guides for each platform:

JavaScript (Web): After configuring parameters like service name, preview the flashcatRum.init() initialization code in real-time
Android: Shows complete integration steps including adding Gradle dependencies (cloud.flashcat:dd-sdk-android-core and cloud.flashcat:dd-sdk-android-rum), initializing the SDK in Application.onCreate() with RUM enabled, and optional WebView tracking integration
iOS: Shows complete integration steps including adding Swift Package Manager dependency (fc-sdk-ios, from version 0.6.0), initializing the SDK in AppDelegate.didFinishLaunchingWithOptions with RUM enabled, and optional WebView tracking integration
Flutter: The Flutter SDK wraps the Android/iOS native SDKs, so one integration monitors both platforms. See Flutter SDK Integration
WeChat Mini Program: Fill in env, service, version, and sessionSampleRate in the form. A flashcatRum.init() snippet built on @flashcatcloud/miniprogram-rum is generated as you type (see “WeChat Mini Program SDK Configuration Assistant” below)
Electron: Provides a step-by-step integration guide. Install @flashcatcloud/electron-sdk in the main process and initialize it inside app.whenReady(). Initialization must finish before any window is created. In the wrong order, the SDK reports no error but collects no data. To capture page views, user actions, network requests, and JS errors in your windows, you can also add @flashcatcloud/browser-rum to the renderer process. Its data goes to the main process over an IPC bridge for unified reporting. When bundling the main process with Vite / webpack / esbuild, you can also add the corresponding plugin to keep the SDK’s runtime dependencies. See Electron SDK Integration
React Native: Provides a four-step integration guide:
1. Install @flashcatcloud/mobile-react-native and the view-tracking package for your navigation library (@flashcatcloud/mobile-react-navigation or @flashcatcloud/mobile-react-native-navigation), and run pod install.
2. Wrap the Metro config with withDatadogMetroConfig so release bundles and their sourcemaps carry a Debug ID.
3. Initialize the SDK as early as possible at the app entry. serviceName is required; without it, Android and iOS split into two services.
4. Start automatic view tracking once the navigation container is ready. See React Native SDK Integration

Each platform’s SDK configuration page automatically fills in the current application’s applicationId and clientToken, so you can copy the code directly into your project. The Web, Android, iOS, Flutter, HarmonyOS, and WeChat Mini Program SDK configuration pages all provide an Allow remote configuration switch, which is on by default. When it’s on, the generated code includes remoteConfigurationEnabled: true (.setRemoteConfigurationEnabled(true) on Android and HarmonyOS). When it’s off, that line is omitted and the client never requests the remote configuration. The switch only affects the generated code. You still need to enable and publish a configuration on the Remote Configuration tab. Until you publish, the client uses the configuration in your code.

Modifying SDK configuration in application management will not take effect in real-time on integrated clients. All configuration changes need to be updated in your frontend code and redeployed to take effect.

Service definition

A service is an independent, deployable code repository that maps to a set of pages.

Monolithic Application
Micro-frontend/Multi-page Application

If your application is built as a whole, your RUM application only needs one service name.

flashcatRum.init({
  applicationId: 'YOUR_APP_ID',
  clientToken: 'YOUR_CLIENT_TOKEN',
  service: 'my-web-app'  // Single service name
});

If your browser application is built from multiple independent repositories, set different service names for different modules.

// Main application
flashcatRum.init({
  service: 'main-app'
});

// Sub-application A
flashcatRum.init({
  service: 'module-a'
});

WeChat Mini Program SDK configuration assistant

For WeChat Mini Program applications, Application Configuration → SDK Configuration shows a Mini Program integration wizard. Fill in the form on the left, and a ready-to-copy initialization snippet appears on the right.

Form fields

Field	Description	Validation	Default
`env`	Environment variable, for example, `prod`, `dev`	Letters, digits, underscore only; up to 24 chars	—
`service`	Service name; all events default to this tag	Letters, digits, underscore only; up to 24 chars	—
`version`	Version number, useful for filtering during analysis	Letters, digits, `.` only; up to 24 chars	`1.0.0`
`sessionSampleRate`	Session sample rate (percentage)	Integer in range `0–100`	`10`
`remoteConfigurationEnabled`	Whether the generated initialization snippet enables remote configuration	—	On

No save action is needed — the preview snippet updates as you type. applicationId and clientToken are filled in automatically by the system; you do not need to set them by hand.

Two-step integration

Add Dependency

Install the SDK in your Mini Program project and run the npm build through WeChat DevTools:

npm install @flashcatcloud/miniprogram-rum

Copy the Initialization Snippet

Use the copy button at the top-right of the right-hand code block, then paste the generated snippet into your Mini Program’s app.js:

import { flashcatRum } from '@flashcatcloud/miniprogram-rum';

flashcatRum.init({
  applicationId: "<APPLICATION_ID>",
  clientToken: "<CLIENT_TOKEN>",
  service: "<SERVICE_NAME>",
  env: "<ENV_NAME>",
  version: "1.0.0",
  sessionSampleRate: 10,
  remoteConfigurationEnabled: true // Apply settings published in the console
});

For the full SDK capabilities, collection toggles, and event reporting model, see WeChat Mini Program SDK Integration.

Link integration

Link Integration lets you associate RUM events with external systems, such as distributed tracing platforms, log search, object storage that stores crash log packages, or internal troubleshooting systems. After you configure links, RUM generates jump links from the event type and event context and shows them as Related Links in event details. Link Integration is available from the Link Integration tab on the application details page and applies to every application type. Members with the RUM Application Update permission can add, edit, enable, disable, or delete link configurations.

Built-in tracing

The built-in Tracing card is the default Link Integration entry. It links the trace_id on resource events to your backend tracing system.

Enter the jump link

In the Link Integration tab, find the Tracing card and enter the jump link for your tracing system. You can use the ${trace_id} variable in the link. RUM replaces it with the actual Trace ID from the resource event when it displays the link.For example: https://your-tracing-system.com/trace/${trace_id}

Enable Tracing

After you save the jump link, turn on the Tracing switch. The switch cannot be enabled until a jump link is configured.

Built-in Tracing only matches resource events, and it appears only when the event contains trace_id. The jump link must start with http:// or https://.

Add external links

Besides built-in Tracing, you can add custom external links for different event types.

Add a link

In the Link Integration tab, select Add external link, then enter the link name and the jump link.

Choose applicable event types

Choose the event types where this link should appear. The supported types are Crash, Error, View, Action, Resource, and Session.A crash is an error event: selecting Error matches both regular errors and crashes, while selecting Crash matches only crash events.

Insert variables and preview

Insert variables in the Jump link, such as ${session_id}, ${error_id}, or ${trace_id}. The page previews the final URL with sample values so you can verify that the template matches your external system’s query format.

Setting	Description	Rule
Link name	External system name shown in RUM event details	Required
Applicable event types	Controls which RUM events show the link	Select at least one event type
Jump link	External system URL that can include `${variable}` tokens	Must start with `http://` or `https://`
Per-link switch	Controls whether this external link is active	Disabled links are not shown

Available variables

Link Integration extracts variables from the current event context and substitutes them into the URL template.

Variable	Description	Common Event Scope
`${session_id}`	Session ID	Session, View, Action, Error, Resource
`${view_id}`	View ID	View, Action, Error, Resource
`${action_id}`	Action ID	Action, Error, Resource
`${error_id}`	Error ID	Error, Crash
`${resource_id}`	Resource ID	Resource
`${trace_id}`	Trace ID	Resource, built-in Tracing
`${application_id}`	RUM application ID	All events
`${service}`	Service name	Events that collect `service`
`${version}`	Version	Events that collect `version`
`${env}`	Environment	Events that collect `env`
`${usr_id}`	User ID	Events that collect user information
`${usr_name}`	User name	Events that collect user information
`${usr_email}`	User email	Events that collect user information
`${start_time}`	Start time of the current event detail query	Explorer event details, Error Tracking issue error samples
`${end_time}`	End time of the current event detail query	Explorer event details, Error Tracking issue error samples

Not every variable resolves on every event type. The editor checks variables against the event types you select. Variables that can’t resolve appear as dashed grey chips. Hover over one to see which event types can’t resolve it.

Variable	Session	View	Action	Error/Crash	Resource
`${session_id}`	✓	✓	✓	✓	✓
`${view_id}`	✗	✓	✓	✓	✓
`${action_id}`	✗	✗	✓	✓	✓
`${error_id}`	✗	✗	✗	✓	✗
`${resource_id}`	✗	✗	✗	✗	✓
`${trace_id}`	✗	✗	✗	✗	✓
`${usr_id}`, `${usr_name}`, `${usr_email}`	✓	✓	✓	✓	✓
`${service}`, `${version}`, `${env}`	✓	✓	✓	✓	✓
`${application_id}`, `${start_time}`, `${end_time}`	✓	✓	✓	✓	✓

A variable is available if the event type’s table has the field, whether or not a given event has a value. Available means the event type can resolve a value, not that every event has one. Crashes are error events, so they share the error column.

If the template uses a variable that can’t resolve, the editor shows a warning below the input. In a query parameter, the whole parameter is dropped from the generated link. In the path, the literal ${variable} text is kept. The sample preview (sample data) omits the sample values of unavailable variables, so the preview matches what production actually resolves.

Legacy configurations that select the All event type only guarantee ${session_id} among the ID variables (the “all” scope is the intersection of every event table’s columns). Prefer concrete event types so the editor can validate availability accurately.

Put optional variables in query parameters, for example https://logs.example.com/search?session=${session_id}&error=${error_id}. If a query parameter only contains a missing variable, RUM omits that parameter when generating the link. Missing variables in the URL path stay as the original ${variable} text.

When an event matches an enabled link configuration, you can open the external system from these locations:

RUM Explorer event details: the Related Links dropdown appears in the top-right corner for event details such as Session, View, Action, Error, and Resource
Error event details: matching related links appear as embedded cards in the details area, with copy and open actions
Issue error samples: matching related links appear below the error sample, so you can jump from an Issue directly to logs, tracing, or another troubleshooting system

Privacy settings

Privacy settings allow you to control the scope of user privacy data collected by the RUM SDK, meeting data compliance requirements for different regions.

Setting	Description	Associated Fields
Geo-location Information	Controls whether to collect user country, province, city, and other geographic information	`@geo_country`, `@geo_province`, `@geo_city`
IP Address	Controls whether to collect user IPv4 and IPv6 addresses	`@geo_ip_v4`, `@geo_ip_v6`

After disabling geo-location or IP address collection, the related filter and analysis dimensions will no longer be available. Please adjust carefully based on your business requirements and compliance needs.

Code repositories

The Code repositories tab links a RUM application to the repositories that build it, so that AI SRE can go straight to the code when it analyses a problem. The tab collects no data of its own and does not change what the SDK reports. The tab only appears when the account has AI SRE enabled (always on for SaaS; on private deployments it follows the enableAiSre switch in the deployment configuration). Authorizing repositories and managing the access scope happen in Plugins → Apps, see Apps.

Adding a repository

Open the tab

Select the Code repositories tab on the application detail page. With no repository linked yet, the page shows “No repositories linked yet”.

Enter the repository

Click Add repository and type owner/name in Repository, or paste a GitHub web or clone URL (HTTPS or SSH) — it is normalized to owner/name on save.The input offers suggestions in two groups, but never fills them in for you. Granted to the GitHub App lists repositories that the account’s GitHub App installations can access. From symbol uploads lists repositories seen in this application type’s symbol uploads over the last 90 days. If your repository is not among them, type or paste it directly.

Enter the directory

In Directory, enter the path of the application inside that repository; use . for the repository root.

Save

Click Save. Afterwards you can reorder with ↑ Set as primary on any entry that is not the first one, or remove an entry (removal asks for confirmation).

Rules and limits

Item	Rule
Number of repositories	At most 10 repositories
Repository format	A GitHub repository in `owner/name` form (owner at most 39 characters starting with a letter or digit; name at most 100 characters)
Primary repository	The list is ordered; the first entry is the primary repository and carries the Primary badge
Directory	A relative path inside the repository, at most 255 characters, with no `..` and no backslashes; on save leading and trailing `/` are trimmed, `.` segments are dropped, and an empty value is normalized to `.`
Duplicate links	The same repository with the same directory cannot be linked twice (repository names compare case-insensitively)
Permission	Adding, removing, and setting the primary repository require the RUM App Update permission

The repository names shown in the list link to the corresponding repository on GitHub.

How it relates to AI SRE

Linking a repository grants no access by itself. AI sessions in the cloud sandbox can reach only repositories granted to the account’s GitHub App installations. Manually entered repositories matter only for BYOC sessions, which use the host’s own credentials.
When the account has no GitHub App connected, a banner warns that cloud AI sessions cannot read manually entered repositories and offers a Connect entry (Plugins → Apps).
With a GitHub App connected, repositories outside its granted range carry a warning mark, meaning cloud AI sessions cannot read them. Members with Apps plugin access can click the mark to grant more repositories under Plugins → Apps; other members need to ask an admin.
Deployments without a GitHub App (such as RUM-only private deployments) support manual entry only and show no connection banner.

Remote configuration

The Remote Configuration tab lets you adjust collection and privacy parameters online, without code changes or a new release. When enabled, the configuration on this page overrides SDK initialization settings. When disabled, clients fall back to their SDK initialization settings and data collection continues uninterrupted.

Remote Configuration is currently available for Browser, iOS, Android, Flutter and WeChat Mini Program applications. Other platform types will be enabled as their SDKs ship support.
The Remote Configuration tab is open to every account, on SaaS and private deployments alike — there is nothing for support to enable. Whether the tab appears depends only on whether the application type is one of the supported platforms listed above.

Configuration values

Field	Values	Description
Session sample rate	Integer 0–100 (%)	Percentage of sessions collected. Leave it empty to skip delivering this field; clients keep the value set at SDK initialization
Session replay sample rate	Integer 0–100 (%)	Percentage of sessions recorded by Session Replay. If empty, the SDK setting applies
On-error session capture (`sessionOnError`)	On / Off / Use SDK setting	For sessions missed by session sampling, uploads up to the last minute of events on error and continues collection; requires Web SDK 0.3.0 or later
On-error replay capture (`sessionReplayOnError`)	On / Off / Use SDK setting	For collected sessions missed by replay sampling, uploads buffered replay on error and continues recording; requires Web SDK 0.3.0 or later
Trace sample rate	Integer 0–100 (%)	A second session-level sampling pass within already-collected sessions, deciding which sessions inject trace headers into eligible requests; the outcome is consistent within one session. Overall trace coverage is roughly session sample rate × trace sample rate. If empty, the SDK setting applies
Replay privacy level	`mask` / `mask-user-input` / `allow`	Default masking of page content in Session Replay: `mask` obscures text and hides input values; `mask-user-input` keeps page text and hides only what users typed; `allow` records the page as it is. Loosening the level starts collecting content that was not collected before, and replays already uploaded cannot be retroactively masked. The console asks you to confirm again before publishing
Custom configuration keys	Key–value pairs typed as string / number / boolean / JSON	Delivered to clients together with the remote configuration and read by your application code; the platform does not interpret them. Up to 5 keys; each key name is at most 64 bytes (counted in UTF-8, not characters), each value at most 4 KB and nesting at most 3 levels (objects and arrays each count one level), and all custom entries together at most 16 KB

The two on-error options are independent: On delivers true, Off delivers false, and Use SDK setting omits the field so the corresponding init() option applies (off if unset). Browser applications require Web SDK 0.3.0 or later with remoteConfigurationEnabled: true at initialization. Turning off on-error capture does not affect sessions selected by ordinary sampling. See Web SDK on-error session capture for scope, billing, and limitations. iOS, Android, Flutter, and WeChat Mini Program applications also show the Remote Configuration tab. Their SDKs read only the session sample rate and custom configuration keys. None of them has Session Replay, and the other values have no effect. Every SDK has to opt in with remoteConfigurationEnabled: true at initialization (off by default; an application that has not opted in never requests the configuration). Minimum versions:

iOS: SDK 0.6.0. See iOS SDK Advanced Configuration.
Android: SDK 0.7.0. See Android SDK Advanced Configuration.
Flutter: flashcat_flutter_plugin 0.2.0. See Flutter SDK Advanced Configuration.

Custom entries are delivered to clients and may be readable by end users. Never put secrets, access tokens, or personally sensitive information in them.

Conditional rules

Conditional rules are reserved in the protocol, but the console doesn’t let you edit them yet. There’s no rule editor on the page. Saving a configuration keeps the rules already stored on the server. Rule editing will open up in a later version. For reference, the protocol semantics: besides the default values, a configuration can deliver different values to different clients based on conditions —

Match conditions support the env, app_version, and sdk dimensions, ANDed with exact comparison; a dimension the SDK does not report can never match. Each match value is at most 256 bytes.
Rules are evaluated top-down, and the first fully matching rule wins. Its overrides are merged on top of the defaults, and unset fields keep their default values.
Each application supports at most 20 rules.

Publishing and activation

Before publishing, the page shows a per-field diff against the live configuration and lets you inspect the raw JSON. You can optionally fill in a change note (at most 255 characters, for example, “lower the sample rate during the sale event”), which is stored on the version and shown in the change history. Publishing creates a new version.
Activation is fixed to next new session. Running sessions are unaffected, and new sessions pick up the configuration over time. Clients that support remote configuration usually switch within about 4 hours of a publish.
Immediate activation ends the running session as soon as a new configuration arrives and starts a fresh one. It’s reserved in the protocol, but the console doesn’t offer it yet. In urgent cases, such as stopping over-collection or ramping up collection right away, call the SDK’s stopSession(). The current session ends, and the configuration applies to the next one.
The protocol also reserves a refresh on foreground switch (refresh_on_foreground): when on, the client re-fetches the configuration every time it returns to the foreground instead of waiting for a poll. It’s off by default, because every client requesting at the same foreground moment concentrates load on the configuration endpoint, like a release herd. Use it only when a change must land within minutes. The switch cannot be set in the console yet and will open up in a later version.

Version history and adoption

Change history keeps the most recent 50 versions; older versions are cleaned up automatically and cannot be rolled back to. Each entry shows who made the change and the change note (if one was left). You can revert any retained version to make it the current configuration; a revert also produces a new version.
A version created by a revert carries a content-equivalence label. If its content matches an earlier version, the history marks it as equivalent to the earliest version with that content. A new version number doesn’t mean the content changed.
The rollout panel shows adoption across recently arrived sampled sessions: a waffle chart of 10×10 = 100 squares represents each version’s share of sessions, where each square is 1% of sessions, estimated from each version’s sample rate, and the detail table next to it lists the Version, Share, and Sessions of every group. The figures above show four statistics — Active sessions, Reported, Not reported, and Current version adoption — and current-version adoption carries a check mark labelled recent sessions switched once every session that arrived in the window has switched. Groups are merged as follows: the current version forms a group of its own, labelled Current; the two older versions with the highest share each form their own group; the remaining older versions are merged into Earlier versions; and sessions that did not report a configuration version are listed separately as Not reported (SDK too old or config never fetched). Status labels are waiting for new sessions (just published, no session has started under the current version yet), in effect (some sessions have switched), recent sessions switched (every session that arrived in the window is on the current version), no configuration received (none of the recent sessions reported a configuration version — usually the SDK has remote configuration disabled or is too old), no data (no new sessions in the window), and no adoption detected (published for over about 8 hours and still not on the current version). Click View session details to open these sampled sessions in the event explorer. On the version card, View config expands the current configuration, and Hide config collapses it. With fewer than 20 sampled sessions in the window, the panel shows only the actual session counts per group, with no waffle chart. Shares are extrapolated from the sample rate, which is meaningless with so few samples.

Delete application

If you no longer need an application, you can find the delete button at the bottom of the “Basic Info” tab in the application details.

After deleting an application:

No new events will be received
The application’s Client Token will be immediately revoked
Previously collected RUM event data can still be manually exported, or you can contact the support team to restore the deleted application

This operation requires the RUM Application Delete permission.

Next steps

SDK Integration Guide

Learn how to integrate RUM SDK

Advanced Configuration

Learn about advanced configuration options for the SDK

Analytics Dashboard

View and analyze RUM data

WeChat Mini Program SDK

Learn how to integrate the RUM SDK into a WeChat Mini Program

Quick Start

Analytics

SDK Integration

Performance

Error Tracking

Explorer

Session Replay

Best Practices

Others

Overview

Application permissions

Create application

SDK configuration

Service definition

WeChat Mini Program SDK configuration assistant

Form fields

Two-step integration

Link integration

Built-in tracing

Add external links

Available variables

Privacy settings

Code repositories

Adding a repository

Rules and limits

How it relates to AI SRE

Remote configuration

Configuration values

Conditional rules

Publishing and activation

Version history and adoption

Delete application

Next steps

SDK Integration Guide

Advanced Configuration

Analytics Dashboard

WeChat Mini Program SDK

​Overview

​Application permissions

​Create application

​SDK configuration

​Service definition

​WeChat Mini Program SDK configuration assistant

​Form fields

​Two-step integration

​Link integration

​Built-in tracing

​Add external links

​Available variables

​View related links

​Privacy settings

​Code repositories

​Adding a repository

​Rules and limits

​How it relates to AI SRE

​Remote configuration

​Configuration values

​Conditional rules

​Publishing and activation

​Version history and adoption

​Delete application

​Next steps

SDK Integration Guide

Advanced Configuration

Analytics Dashboard

WeChat Mini Program SDK

Overview

Application permissions

Create application

SDK configuration

Service definition

WeChat Mini Program SDK configuration assistant

Form fields

Two-step integration

Link integration

Built-in tracing

Add external links

Available variables

View related links

Privacy settings

Code repositories

Adding a repository

Rules and limits

How it relates to AI SRE

Remote configuration

Configuration values

Conditional rules

Publishing and activation

Version history and adoption

Delete application

Next steps