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.
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.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:
Fingerprint Calculation Rules
When an error event doesn’t carry a fingerprint, Flashduty automatically calculates one based on the following error attributes:Custom Fingerprint
If default grouping doesn’t meet your needs, you can fully control error grouping behavior by providing a custom fingerprint.- Manually Add Fingerprint
- Use beforeSend Callback
When manually reporting errors, add a custom fingerprint via
addError:- 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
beforeSendcallback can also be used to filter irrelevant errors (such as third-party script errors)
Web-Specific Considerations
SourceMap Integration
SourceMap Integration
Upload
sourcemap files to decode minified stack traces, ensuring grouped error stacks can be mapped to original source code.Third-party Script Error Filtering
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: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:Next Steps
Issue Status
Learn about Issue status transition mechanisms