This topic covers the following classifications of verification events, and related options:
For an overview of verification feedback, and steps on applying and changing an event's classification, see:
- Harness Verification Feedback Overview
- Refine 24/7 Service Guard Verification Analysis
- Refine Deployment Verification Analysis
- File Jira Tickets on Verification Events
A Known Event is a non-anomalous event from your baseline execution, as opposed to a Not a Risk event, which is from the current execution.
If you decide that a Known Event should fail deployments, you can remove the Known Event from the baseline and assign it a priority.
Not a Risk
Not a Risk events are events from the current execution that are expected or that have been marked as Not a Risk so that they do not fail the deployment.
Not a Risk means the event is in the baseline moving forward. A Not a Risk event from the current execution becomes a Known Event in subsequent executions.
In many cases, an event is labeled Not a Risk because a Jira ticket for the event has been created and it is being resolved.
For anticipated events that do not need a P# assignment, assign the Not a Risk priority to the event. The events are added to the baseline of the analysis.
You can also change a Not a Risk event to a P# to pull it out of the baseline for subsequent executions.
Anomalous Events fail a deployment. Anomalous Events are events Harness has never seen before and are likely not good. You should assign a priority to the event.
Priority Events fail a deployment. They range in priority from P0 to P5.
Each priority number has a separate color associated with it:
You can change priority levels to specify the priority of the event. When you mark an even with a priority, Harness will identify the event with that priority in future analysis and fail the deployment if the event occurs.
You can assign a Jira issue for any event that has a priority assigned to it. For more information, see File Jira Tickets on Verification Events.If other matching events are discovered in future deployments, they will be assigned the same P#. The matching is performed by text matching with the event log data.
Priority Events in 24/7 Service Guard
While adding priority to events after a deployment is very useful (as described in Refine Deployment Verification Analysis), priority events are especially useful in 24/7 Service Guard.
24/7 Service Guard monitors your live, production application or service. You can mark events that show up in the live monitoring as P0-P5 and assign Jira issues for them, thereby fixing issues as soon as they show up. This prevents issues from surfacing during your next deployment.
Auditing Event Prioritization
Event prioritization is not currently recorded in the Harness Audit Trail, but when a Harness User changes the priority for an event, their name and the timestamp are recorded, and can be viewed by hovering over the priority.