Skip to main content
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

1

Fingerprint Matching

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

Automatic Merging

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

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

​
Default Fingerprint

Flashduty enables error grouping by default, working without additional configuration. The Browser SDK automatically collects error data and performs grouping.
Include the Flashduty Browser SDK in your HTML file:
<script src="https://cdn.flashcat.com/rum-browser-sdk.js"></script>

​
Fingerprint Calculation Rules

When an error event doesn’t carry a fingerprint, Flashduty automatically calculates one based on the following error attributes:
AttributeDescription
serviceService where the error occurred
envEnvironment where the error occurred
error.typeError type classification
error.messageError description text
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.
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",
});
  • 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

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
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:
ContentDescription
Error message and stack traceIf sourcemap is uploaded, shows original source code location
User session timelineOperation path that triggered the error
MetadataBrowser type, version number, etc.

​
Next Steps

Issue Status

Learn about Issue status transition mechanisms