1. Home
  2. Transmogrifier
  3. Transmogrifier: Managing Rules

Transmogrifier: Managing Rules


Versions Supported: Full-Stack 

VictorOps Version Required: N/A SaaS

All alerts are processed through the Transmogrifier before reaching your timeline in descending order (top to bottom).  This means that the order of the rules is very important.  From the main Transmogrifier page, you can click and drag individual rules to re-order them.  By default, any new rules you create will appear at the top of the list.

It is a good general practice to add a detailed description when creating a rule so your fellow admins will understand its purpose.

Click on the symbols at the right side of the bar to edit or view a rule.


Options include the ability to enable / disable (rules are enabled by default), delete, and preview.


To use the preview window, set your matching condition and then click the edit symbol (three horizontal lines) and select Preview.  The preview option opens a small window on the right side of your rules that will display any recent events in your timeline which meet the matching condition you have set.

This allows you to view the content of your alerts without having to switch back to the timeline.  One useful trick is to set a very broad matching condition (use a in the pattern section), then open the preview and find the alert you want to manipulate.  Clicking More Info on the alert shows you the full payload.  Hover over any field and click to automatically populate the matching condition of your rule to match that selection.


To close the preview window, click on the edit symbol again and choose Close Preview.

Scope Limiting

You may encounter situations where wildcard matching is required for a commonly occurring phrase (“down” or “database” for example).  Matching on such a common phrase can cause your rule to be unintentionally applied to alerts that you do not wish to alter.  This problem can be solved by using a sequence of sequential rules to limit the scope of the wildcard matching condition.

For example, lets say we want to catch the word “staging” in the entity_id field and convert those alerts to INFO alerts so we don’t create an incident and notify anyone at 3:00 AM for a problem in a staging environment.  However, there are some cases where you do want to create an incident for the staging environment, so creating a single rule to match on the phrase “staging” could prevent that from happening.  In this case we only want to affect alerts from one particular monitoring tool (New Relic).

First, we need a rule to match on the monitoring tool value.


The matching condition for this rule catches all alerts from New Relic.  It then uses a transformation action to declare a new field (new_relic_staging) and uses variable expansion to import the value of the entity_id field into that new field.  This means that all alerts from New Relic now have a new field that is unique to New Relic only.  The subsequent rule will now use wildcard matching on that new field.


This second rule (MUST BE POSITIONED BELOW THE FIRST RULE!) matches on the new field created by the first rule, using wildcard matching to catch the phrase “staging”, and then takes the appropriate action.  This limits the scope of the wildcard matching rule to only alerts from New Relic.

AND / OR Logic

OR logic can be achieved by simply replicating a rule with a different matching condition.

Using a set of sequential rules, when ordered correctly, can achieve basic AND logic in the Transmogrifier.  As with scope limiting rules, the first rule must create a new field which can be acted upon by a subsequent rule.

AND Logic Example

Let’s say you want to catch the phrase “disk space” from the entity_id  field AND the name “stage-db-26” from the host_name  field to convert these alerts to INFO events only when both these conditions are met.

The matching condition for the first rule will catch the first desired phrase and use variable expansion to import the value of the second field into a newly declared field.


The matching condition for the second rule (MUST BE POSITIONED BELOW THE FIRST RULE!) checks the newly declared field for the value “stage-db-26” and takes the appropriate action.


Updated on August 21, 2018

Was this article helpful?

Related Articles