Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 10

Alert organizing question

Jump to solution

Since SolarWinds suggest using OOB alerts at template and you cannot modify them anyway, do you think it's a good idea to disable all of the OOB alerts that you may use, make copies of them, and then apply the copied alerts to the environment?  The SW best practice is to use OOB alerts as templates so I'm thinking of disabling all of the alerts and using any of them I need as templates.  This would allow anyone coming after me to modify the alerts as needed while keeping all of the original alerts in their original state.

1 Solution

nato​, yes, that is correct. We make copies of the OOB alerts we want/need to use, then disable all OOB alerts. We only use the copies we made.

We feel, as do many others, it is better practice to use the OOB alerts simply as a template. Everyone has a different environment, so each environment needs its own modifications.

View solution in original post

21 Replies
Level 16

We have always disabled all of them and then copied the ones we want to use. We also came up with a naming scheme for them so for example if it's a SAM alert it is indicated in the name and then there is an associated number with it so we can match up a SAM template with an alert name.

Also in the alert actions we always include the alert name somewhere in the alert. This was done so that later down the road when someone sends you the email alert they received you can match it up with an alert.

Once you get several hundreds of alerts built going to different teams its a great time saver.

Bob -

Can you share your naming convention?  Thanks!

0 Kudos

Here is an example of an alert name

Splunk-0132-BAM-Info-Routing Change-Alert text, this is what the alerts says

The way this name is broken down in our environment is shown below. We separate the fields with a '-' so we can regex them later if needed.

(1.System that generated the alert)-(2.Unique Number Identifier)-(3.Three letter initials of alert author)-(4.Alert Severity)-(5.Alert Name)-(6.Placeholder for the text that will be passed on from the alert)

In our environment we pass alerts around between systems so the six fields are used for different reasons for different systems.

Thanks Bob!  Very helpful!

bobmarley​ We do something very similar with the naming convention too.


Luther -

So in your image, each number corresponds to a prefix number corresponds to a different module within SW is that correct?  And what is the suffix for?

0 Kudos

feltonlewis​ Before rebuilding our latest Orion environment, we had previously had several hundreds of alerts. While I wanted to have all of our alerts streamlined and using custom properties, I also wanted a better way to sort through and identify them. I ended up going with a prefix number and a suffix number to help keep them in categories. I do not like how the default "Group By" options display the alerts, breaking simple groups down into overly specific sub-groups. I do, however, like the simplicity of the "Manage Custom Properties" page, where it groups by the most simplistic of categories. (Alerts, Apps, Groups, Nodes, Ints, etc..)

Basically, yes, the idea was to just keep similar alert types grouped together. (all node alerts with the a prefix in the range of 100-199, interface alerts start with 200-299, and so on).

The suffix was mainly just for me when I need to go in and update the alerts, or make any major changes. I prefer to keep old alerts for reference rather than delete or change them altogether. So, whenever I need to update/change an alert, I simply copy it, make my changes, and increase the suffix.

Group By Object - Manage Alerts


Group By Object - Manage Custom Properties


It's nothing more than a personal preference. I'm sure there are much better ways to do this, but it was simple enough, and works for us, so I went with it.

Thank you,


I reread you post.  I see you're using the suffix for versioning.

0 Kudos

We use a company-specific suffix on our alert configurations. When using a prefix, sorting by alert name becomes much less helpful unless you are already filtering by object type, etc.

We do as well. We are running a shared instance of Solarwinds that supports multiple companies.

Yes. Very yes. My primary reason (but not only) for saying so is that most customization that you make to the OOB alert configurations are lost every time you upgrade Orion. For example, if you put useful information (please do) in the alert message field, most upgrades will reset this to the default, and you'll have to redo every alert configuration.

feltonlewis​ That's pretty much how we do it. Make a copy of the alerts we need to use, then modify those copied alerts to fit our needs. We only use the alerts we need, and everything else is disabled.

feltonlewis We do the same thing. Too many alerts and too many messages make people ignore whatever is going on making them pointless.

@wluther So you make a copy of teh OOB alert then edit it and use it??? So you dont use any OOB alerts?

0 Kudos

nato​, yes, that is correct. We make copies of the OOB alerts we want/need to use, then disable all OOB alerts. We only use the copies we made.

We feel, as do many others, it is better practice to use the OOB alerts simply as a template. Everyone has a different environment, so each environment needs its own modifications.

View solution in original post

Thanks wluther​. I would to see the variables you use alerting in email...

0 Kudos

nato​ this may help with using custom properties:

Success Center  - Use Custom properties when sending email alerts

medleyp812​ That's a good one to develop- looks hard- but most of SW looks hard at first...

nato​ I was thinking the exact same thing at first too. The more you look at it (and use custom properties) the easier it becomes to understand. I just started using custom properties a lot, in alerting and dynamic queries especially. I'd highly recommend it!

nato​ Well, unfortunately, it's pretty plain and simple for the most part, and nothing fancy going on. The most important change we made was jumping onto the dynamic To/CC/BCC bandwagon a while back.

By adding these custom properties to the nodes/interfaces/volumes/etc., you are able to send your alerts dynamically, based on the values provided on the element.


This prevents you from needing multiple copies of the same, or similar, alerts, each copy going to different email addresses. Now, we can have a single node down alert, but it will send it to the various folks depending on the node custom property values.

So, our "Lab" nodes are sent to the person working on them, as their email address is added to the node. The server nodes have the server engineer email on them, and the various network devices are split up among the network ops and engineers accordingly.

In general, custom properties are really the key to many workflows, if not all of them. Besides emails, I use custom properties to build our tabs, or add numerous graphs to a view. I have also used custom properties to automatically provision specific values into other custom properties.

I think, as with most things, if you spend enough time planning things out around some basic custom properties, you will find a severe increase in efficiency later on down the road. It's definitely one of those things where a little extra time up front can deliver big savings later on.

Thank you,