Verification Event Classifications

Updated 8 months ago by Michael Cretzman

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:

Known Event

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

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

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.

See:

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.

How did we do?