Notification aggregation is applied to each notification type (push, sms, email and phone) on a per user basis. This means push notifications going to user A are aggregated separately than SMS for user A. Each time a notification is sent out it is cumulative for the total # of incidents for that user.
The current notification settings are:
- Push, SMS, Email: 3 events / 60 seconds
- Phone: 1 event / 2 minutes
Aggregation does not trigger until there are at least 3 incidents opened in a 60 second period. Below is an explanation of a few different scenarios.
|Action in Timeline||Aggregation||Expected Response|
|Two incidents are created in the Timeline in under 60 seconds||x||Notifications sent out for both incidents to the user(s) on-call|
|Four Incidents are created in the Timeline in under 60 seconds||✓||Three notifications sent out during the first minute then one in the following minute|
|Ten Incidents are created in the Timeline every minute for five minutes||✓||Three notifications sent out during the first minute and then one for the following 4 minutes|
VictorOps aggregates alerts based on the entity_id field value within the incident payload. Below, in the Timeline, you will see incident #929 and four subsequent alerts tethered to it. If an Incident is in an Ack’d or Critical state while multiple alerts with the same entity_id continue to arrive in the Timeline, then the alerts will roll up under the incident and only page out based on the original alert.
And below please see the shared entity_id between the Alert payload and the payload for incident #929:
This alert aggregation works with Critical, Warning, and Ack’d message types as long the entity_id is shared between events. For more information regarding fields like entity_id and message_type please see our Glossary of Fields documentation found here.
Please Note: Alerts aggregating under a Warning message_type will aggregate normally unless the message_type value of the alert changes status from Warning to Critical. If this value changes (escalates) in status from its source then any Ack’d incident will “Pop of of Ack” and return to a triggered state to start paging an on-call user.