Custom Violation Descriptions Fully Rendered in NrAiIncident

Hey there !

For all of y’all that are using Custom Violation Descriptions, you should be pleased to know that we are now fully interpolating the variables in the description field prior to publishing the NrAiIncident event.

For those that are not familiar with the NrAiIncident NRDB Event Type, whenever an Incident (formerly known as a ‘Violation’) is opened or closed in your account, we write out an event record to your NRDB account that captures all of the details of that event. Before today, when we wrote out the contents of the Custom Violation Description to the NrAiIncident event, we used the raw input text. We did not interpolate the variables into the event specific values. As of today, when we write out this event, we will use the fully interpolated string.

This field has always been fully interpolated when it appeared in your notifications. Very soon, it will appear fully interpolated on the new Incident and Issue pages as well. Having these Custom Violation Descriptions appear on Incident pages can serve as an inline, mini runbook for the specific incident.

So… If you add a Custom Violation Description that looks like this:

Then, when you look at your NrAiIncident Events, you will see the following:


Hey @bgoleno, thanks for this useful addition - using the li’l custom violation descriptions as mini-runbooks for our incident response team is exactly our use-case, so anything to share more clarity is greatly appreciated. It’s perfect for conditional-routing of incidents when integrated with PagerDuty as well.

For the longest time, it was annoying that the “see our docs for a full attribute list” link led to a screenshot of text rather than a comprehensive, copy-pasteable table of attributes with descriptions. Given this update, please can this be amended to a more documentation-friendly format with a full list of potential attributes?


Hi @Rishav

I’m going to look into changing that documented example, so that the screenshot shows the same as what is shown in the example below.

can this be amended to a more documentation-friendly format with a full list of potential attributes?

The problem with this is that there is a long list of potential attributes. It all depends on what event type is being queried and what is being faceted on – any event type can be queried (even custom event types), any attribute can be faceted on, and any faceted attribute can be included in the violation description. We can’t show all these attributes in a list.

That said, a full list of violation event attributes is shown in this documentation. I will work on getting this more clearly documented.


That table of attributes is exactly what I was looking for, @Fidelicatessen, thank you.

1 Like

@Rishav Great to see @Fidelicatessen was able to help!

1 Like