Skip to main content
After errors are reported, you can view Issues in the Error Tracking module. In RUM, an Issue is a group of similar errors, typically related to the same bug.
Issue List
For detailed grouping rules, please refer to Error Grouping.

​
Issue Information Overview

Issue Information Overview
Each entry listed in the Issue browser contains the following information:

​
Issue Status

Issues have 4 statuses, with transitions as follows:
Issue Status Transitions
For regression-related transition logic, please refer to Issue Status.

​
Filtering and Sorting

The timeline in the upper right corner of the browser allows you to display Issues that had errors during the selected time period. You can:
  • Select a preset range from the dropdown menu
  • Directly modify the time
  • Enter natural language for filtering

​
Error Cause Classification

Flashcat adds an error cause classification to each Issue when created, helping improve fault localization efficiency.
When hovering over an error cause classification, the system will use AI capabilities to provide inferred root causes and fix suggestions.

​
Classification Mechanism

The system uses a two-layer analysis mechanism to classify errors: Layer 1: Pattern Matching The rule engine checks error types and messages in priority order; the first matching rule determines the classification: Layer 2: AI Inference When pattern matching results in “Unknown Error”, the system invokes an AI model for deeper analysis. The AI model evaluates the following information:
  • Error Message: The error description text
  • Stack Trace: The complete call stack
  • Platform Type: Browser/JavaScript, Android/Kotlin/Java, iOS/Swift/Objective-C, WeChat Mini Program, etc.
The AI outputs an error classification and a brief cause explanation (up to 100 words). Inference results are displayed as hover tooltips on the Issue card, helping you quickly understand the root cause of the error.

​
Regression

Regression refers to previously fixed bugs reappearing.
Regression
If an error is marked as resolved but the same error occurs later (with a different version), the Issue status will be reopened from the closed state and marked as “Regression”.

​
Issue Details

The Issue list supports two viewing modes: sidebar mode and fullscreen mode. By default, the details panel opens as a sidebar. You can click the expand button to switch to fullscreen mode for a more spacious view and more complete data display. Click any Issue to open the details panel and view more information.
Issue Details
The top of the panel displays basic Issue information, such as status and error cause. You can also understand the Issue lifecycle: first and last occurrence dates, duration, and error occurrence count over time (aggregated by time granularity).
In the label distribution section, you can view the proportion of different labels under this Issue across various dimensions, quickly determining the impact scope and helping locate root causes.Currently supports labels like view_name, browser_name, version, env, etc.
By default, displays the most recent error information reported during the Issue’s occurrence as an error sample. You can also switch through the navigation bar.For native crashes, each sample in the navigation list carries a symbolication badge (“Parsed” / “Unparsed”). When the latest sample cannot be symbolicated but an older sample can, the detail auto-switches to the symbolatable sample and shows the notice “Switched to a sample that can be symbolicated (the latest one is not).” Click “Back to latest” to return to the most recent sample. The auto-switch tries at most 5 older samples; if none of them can be symbolicated, the detail switches back to the latest sample and stops auto-switching.
View error context and stack information. If the corresponding SourceMap, Android mapping file, iOS dSYM file, or Flutter symbol file has been uploaded, you can see mapped original source code locations and code snippets.
Error Stack
You can view uploaded source code information in “Application Management” - “Source Code Management”. See Source Mapping for details.
The error stack display for native platforms (Android/iOS) is specifically designed for mobile characteristics, providing the following capabilities:Pretty / Raw Mode Toggle
  • Pretty Mode: Displays structured stack information, automatically distinguishing between app frames and third-party frames. Third-party frames are collapsed by default, highlighting your own code
  • Raw Mode: Displays raw stack text for easy copying and analysis in external tools
Symbolication StatusIf the corresponding version’s symbol files (Android mapping or iOS dSYM) have been uploaded, obfuscated addresses in the stack are automatically restored to readable function names, file names, and line numbers. When not symbolicated, the system prompts you to upload symbol files with direct links to “Source Code Management” and the upload tool.Symbolication results are cached. After uploading symbols for a crash you have already seen, click the “Re-symbolicate” button in the notice bar or in the “Symbols required by this crash” section to bypass the cache and force a full re-run of symbolication (including re-fetching dSYMs), then refresh the stack — no need to wait for a new occurrence.Thread Stacks (Threads)Native crashes typically involve multiple threads. The thread panel displays stack information for all threads at the time of the crash, supporting:
  • Viewing total thread count and currently displayed threads
  • Expanding/collapsing all threads
  • Independent separation of app frames and third-party frames within each thread, with third-party frames expandable on demand
  • The crashing thread’s stack is displayed first
Binary Images (iOS)For iOS crashes, you can also view the list of Binary Images loaded at the time of the crash, including image names, address ranges, and UUIDs, for offline symbolication analysis.Symbols Required by This Crash (Non-System)When a crash carries non-system binary images (native crashes that resolve addresses through binary images, such as iOS and Electron, including Flutter’s iOS native crashes), a “Symbols required by this crash (non-system)” section appears above the stack, listing every non-system binary image this crash references and its symbolication status:
  • The section header summarizes the status as “symbolicated/total symbolicated”; it collapses to a one-line summary when everything is resolved and expands by default while anything is missing
  • Each image is a row showing its name, UUID, and a “Parsed” / “Unparsed” badge, with a copy-UUID button
  • “Look up in symbol list” opens the Source Mapping page pre-filtered by that image’s UUID
  • Unparsed images also provide an “Upload” link that goes straight to the upload entry of the Source Mapping page
  • While anything is unresolved, the “Re-symbolicate” button in the section forces a fresh symbolication run and refreshes the stack
Flutter SupportFlutter native crashes (with source_type of ndk, android, or ios) carry thread stacks and Binary Images, and are rendered with the same native view described above as Android/iOS native crashes. Dart exceptions are symbolicated by matching the build_id in the stack against uploaded Flutter symbol files.Electron SupportElectron errors are routed by type: main-process and renderer JavaScript errors are V8 stacks and render exactly like browser errors in the Web stack view (original source is restored once a source map is uploaded), while minidump native crashes are address-style native stacks (with threads and binary_images) rendered in the native stack view above — uploading matching Breakpad symbols restores function names, file names, and line numbers. See Electron error symbolication.For detailed symbol file upload procedures, see Source Mapping.
View the total number of Session events for the current error sample, as well as user resource access and operations before and after the error occurred.
Currently displays up to 20 context items including the current Error event. You can view more log information in the Session Viewer module later.
If the session has replay data collected, you can click the “View Replay” button to jump directly to the session replay page, recreating the complete user operation path when the error occurred from the user’s perspective.
Error events carry a series of attributes when reported. You can view current Session, view, user, and other information in the attributes section to help troubleshoot issues.For Electron errors, the attributes panel additionally shows a virtual process attribute (main process / renderer process) in the Other attribute group, indicating which runtime the error came from; non-Electron errors do not show this attribute.

​
Issue Alerts

Discover problems immediately when they occur, giving you the opportunity to proactively identify and fix them before they become severe.
Alert Configuration
1

Enter Application Management

Select an application card and edit it
2

Enable Alerts

Turn on the “Alerts” switch
3

Select Channel

Select the notification channel
For detailed alert configuration instructions, please refer to Issue Alerts.

​
Best Practices

Configure Source Mapping

Facilitates problem localization in production environments

Add User Information

Configure user-related information to provide better error context

Set Alert Policies

Configure appropriate channels and escalation rules for errors

Regular Error Analysis

Regularly check error reports to discover potential issues

Team Collaboration

Use team ownership features to ensure issues are quickly assigned to relevant teams

Monitor Regressions

Closely monitor potential regressions of resolved issues

​
Next Steps

Source Mapping

Configure source mapping

Error Grouping

Learn about grouping mechanisms

Issue Status

Manage Issue status