Error Grouping - Flashduty Docs

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.

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. 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

​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