How To Reduce False Positive Incidents?

False positive incidents occur when a system flags a potential issue that isn't actually a problem. For developers and teams monitoring performance, these false positives can be misleading. They lead to unnecessary investigation, create alert fatigue, and reduce focus on real, critical issues. That's why it's important to minimize these incidents so your team can focus on addressing real performance concerns.

yCrash provides the following features to help reduce false positives on your dashboard.

1. Threshold Settings

yCrash monitors various metrics like garbage collection times, CPU usage, and memory consumption. When these exceed default thresholds, alerts are triggered. However, these thresholds may not suit every application. Customizing thresholds to match your application's specific needs can help reduce unnecessary incidents. Learn more about configuring Threshold Settings.

2. Discard Settings

If certain errors are known issues or not critical in your environment, you can use Discard Settings to suppress them. This feature allows you to define patterns and criteria to ignore certain errors, reducing the number of false positives on your dashboard. Learn more about configuring Discard Settings.

3. Log Discard Settings

In some cases, applications log known errors or warning statements that do not require any action. To prevent these from generating unnecessary incidents, you can configure discard rules in discard-settings-log.json. Any log statements matching the configured rules will be excluded from incident creation, reducing false positives in your reports. For configuration details, refer to the Log Error Discard Settings documentation.

4. m3 Custom Cooling Period

yCrash's m3 feature captures performance incidents and generates reports. To avoid repeated incidnets for the same issue, you can adjust the cooling period, preventing duplicate incidents from being flagged within a short time frame. This helps reduce noise and focuses attention on new problems. Learn more about configuring the M3 Custom Cooling Period.

5. Observation Period

The Observation Period setting prevent incidents caused by brief CPU or memory spikes, reducing false positives. When configured, yCrash will only capture and report an incident if the spike persists for the entire observation period. For instance, if the observation period is set to 3 minutes, only spikes lasting longer than 3 minutes will be considered. This prevents short-lived fluctuations from triggering alerts and ensures the dashboard focuses on real, sustained performance issues. Learn more about configuring the Observation Period.