At Deepfactor, we invest a lot of time to understand and mitigate ‘alert fatigue’ and work very hard to ensure that we show only relevant alerts with actionable information. Our process is as follows:
1. We group similar occurrences of an issue into a single alert so that you don’t see a dauntingly long list of similar alerts.
2. When you navigate to an alert, you are shown the list of all occurrences of that alert.
3. You can then triage each occurrence separately.
4. Based on the triage exercise, you can then add comments per occurrence and also change the state.
The following table describes alert states that are available for each alert occurrence:
| State | Description |
| Reported | This is the default state of an alert occurrence when it is raised by Deepfactor. |
| Acknowledged | Use this state when the occurrence is confirmed by the developers.
NOTE: If you create a Jira ticket for an alert occurrence, the alert occurrence is automatically moved to the ‘Acknowledged’ state. |
| Not an Issue | Use this state when you are certain that this alert occurrence is not an issue in your component, possibly because it cannot be exploited in your environment.
These occurrences will continue to show in the list but will be automatically sorted to the bottom of the list. We strongly advise adding a comment while changing the state to ‘Not an issue’ so as to document the reason for easy reference for other members of your team. |
6. Once you triage and confirm an alert occurrence, you can create a Jira ticket per occurrence of the alert. Since each alert occurrence needs to be fixed separately, we give you the flexibility of raising a Jira at the occurrence level.
7. When you update the state of an alert occurrence, the state persists for that occurrence for newer versions of the same component. However, note that changing the state for an occurrence is scoped to the component. In other words, it does not change the state of the alert occurrence for different components of the same / different application.