Error Grouping

When a new error event occurs, Flashduty uses a three-step aggregation strategy to group errors into Issues, effectively reducing the number of errors that need to be handled.

Grouping Process

Fingerprint Matching

Get the fingerprint of the error event and compare it with fingerprints of existing Issues

Automatic Merging

If the new event shares the same fingerprint as an existing Issue, it is automatically grouped into that Issue

Similarity Analysis

If the fingerprint doesn’t match, machine learning models analyze error similarity and group the event into the Issue with the highest similarity, or create a new Issue if similarity is too low.

Android NDK native crash exception: NDK native crashes (where source_type contains ndk, or the stack contains application-layer native frames) skip the ML similarity analysis in this step and rely entirely on the deterministic fingerprint from Step 1. This is because NDK crash messages (such as signal: SIGSEGV) are nearly identical across unrelated crashes; routing them through similarity analysis would incorrectly merge crashes from different code locations into the same Issue. The frame-aware fingerprint precisely distinguishes different crash sites.Flutter native crashes are handled by their real platform: Native crashes reported by a Flutter app carry source = flutter; during grouping the real platform is resolved from source_type (ndk, android, ios). Crashes whose source_type is ndk (or whose stack contains application-layer native frames) behave exactly like Android NDK crashes — they skip ML similarity analysis and group by the native-frame fingerprint. Crashes whose source_type is ios still group by the message fingerprint, the same as a standalone iOS app.Electron process-gone events skip similarity analysis: Electron process-gone events (whose error.type is RenderProcessGone or ChildProcessGone) also skip ML similarity analysis and group solely by the deterministic fingerprint (error type + message). Every process-gone event reads <process> process gone: <reason> (for example Renderer process gone: killed), so any two events differ by a single token; similarity grouping would incorrectly merge unrelated failures such as “killed” and “launch-failed” into one Issue. The deterministic fingerprint keeps them separate by exit reason.

Default Fingerprint

Flashduty enables error grouping by default, working without additional configuration. The Browser SDK automatically collects error data and performs grouping.

Integrate SDK
Initialize SDK

Include the Flashduty Browser SDK in your HTML file:

<script src="https://cdn.flashcat.com/rum-browser-sdk.js"></script>

When initializing the SDK, specify the application ID and environment:

window.FLASHCAT_RUM.init({
  applicationId: "rum-application-id",
  environment: "production",
  version: "1.0.0",
});

Fingerprint Calculation Rules

When an error event doesn’t carry a fingerprint, Flashduty automatically calculates one based on the following error attributes:

Attribute	Description
`service`	Service where the error occurred
`env`	Environment where the error occurred
`error.type`	Error type classification
`error.message`	Error description text. For Android NDK native crashes, this component is augmented with the topmost application-layer native frame from the stack, in the format `<message>\|native:<library>:<symbol+offset>` (for example, `signal: SIGSEGV\|native:libmyapp.so:crash_func+48`). System library frames (`libc.so`, `libart.so`, etc.) and pseudo-mappings (`[vdso]`, `[stack]`) are skipped, ensuring the same crash location always produces the same fingerprint across different runs.

To improve grouping accuracy, Flashduty removes variable attributes from stack frames, such as version numbers, IDs, dates, and other dynamic parameters.

Custom Fingerprint

If default grouping doesn’t meet your needs, you can fully control error grouping behavior by providing a custom fingerprint.

Custom fingerprints take priority over default fingerprints.

Manually Add Fingerprint
Use beforeSend Callback

When manually reporting errors, add a custom fingerprint via addError:

window.FLASHCAT_RUM.addError(new Error("My error message"), {
  source: "custom",
  fingerprint: "my-custom-grouping-fingerprint",
});

Dynamically set fingerprints via the beforeSend callback:

window.FLASHCAT_RUM.init({
  applicationId: "rum-application-id",
  environment: "production",
  beforeSend: (event) => {
    if (event.type === "error") {
      event.error.fingerprint = "my-custom-grouping-fingerprint";
    }
    return true;
  },
});

Custom fingerprint must be a string type
Errors with the same fingerprint within the same service will be grouped into the same Issue
Errors from different services will be grouped into different Issues even if they have the same fingerprint
The beforeSend callback can also be used to filter irrelevant errors (such as third-party script errors)

Web-Specific Considerations

SourceMap Integration

Upload sourcemap files to decode minified stack traces, ensuring grouped error stacks can be mapped to original source code.

flashcat-cli sourcemaps upload \
  --service my-service \
  --release-version 1.0.0 \
  --minified-path-prefix /assets \
  --api-key your-api-key \
  ./dist

Third-party Script Error Filtering

By default, Flashduty filters errors from browser extensions or third-party scripts (such as network source) to reduce noise.You can further customize filtering rules via beforeSend:

beforeSend: (event) => {
  if (
    event.error.source === "network" &&
    event.error.message.includes("ThirdPartyScript")
  ) {
    return false; // Discard this error
  }
  return true;
};

View Grouping Results

In the Flashduty platform, navigate to “Error Tracking” to view the grouped Issue list. You can also jump there directly from the application list: the Issue count on an application card is clickable, and clicking it opens that application’s error tracking list scoped to match the card — the last 24 hours, status “all” — while clearing any filters left over from a previous visit, so the list count matches the count on the card. Each Issue contains:

Content	Description
Error message and stack trace	If `sourcemap` is uploaded, shows original source code location
User session timeline	Operation path that triggered the error
Metadata	Browser type, version number, etc.

Next Steps

Issue Status

Learn about Issue status transition mechanisms

Quick Start

Analytics

SDK Integration

Performance

Error Tracking

Explorer

Session Replay

Best Practices

Others

Grouping Process

Default Fingerprint

Fingerprint Calculation Rules

Custom Fingerprint

Web-Specific Considerations

View Grouping Results

Next Steps

Issue Status

​Grouping Process

​Default Fingerprint

​Fingerprint Calculation Rules

​Custom Fingerprint

​Web-Specific Considerations

​View Grouping Results

​Next Steps

Issue Status

Grouping Process

Default Fingerprint

Fingerprint Calculation Rules

Custom Fingerprint

Web-Specific Considerations

View Grouping Results

Next Steps