Alignak supports optional escalation of contact notifications for hosts and services.
Escalation of host and service notifications is accomplished by defining
escalations and calling them from your hosts and services definitions.

Tip

Legacy Nagios host_escalations and service_escalations objects are still managed,
but it’s advised to migrate and simplify your configuration with simple escalations objects.

Here, notifications sent before the fist_notification_time
(60 = 60*interval_length*seconds = 60*60s = 1h) will be sent to the contact_groups of the service,
and after one hour and before 4 hours (last_notification_time) it will be escalated to the
level2 contacts group.

If there is no escalations available (like after 4 hours) it fails back to the default service
contact_groups, in this case it is level1.

When defining notification escalations, look if it’s interesting that members of a “lower”
escalation (i.e. those with lower notification time ranges) should also be included in “higher”
escalation definitions or not. This can be done to ensure that anyone who gets notified of a
problem continues to get notified as the problem is escalated.

It can be interesting to have more than one level for escalations.
Like if problems are send to your level1, and after 1 hour it’s send to your level2 contacts
group and after 4 hours it’s sent to the level3 contacts group until the problem is solved
(last_notification_time is 0).

All you need is to define theses two escalations and link them to your host/service:

Recovery notifications are slightly different than problem notifications when it comes to
escalations. If the problem was escalated, or was about to reach a new level, who should be
notified of the recovery?

The rule is very simple: we notify about the recovery every one that was notified about the
problem, and only them.

Here let say you have a problem HARD on the service at t=0. It will notify the level1 contacts
group.
The next notification should be at t=1440 minutes, so tomorrow. It’s okay for classic services
(too much notification is spamming…) but not for escalated ones.

Here, at t=60 minutes, the escalation will raise, you will notify the level2 contacts group,
and then at t=120 minutes you will notify the level3 contacts group, and here one a day until
they solve it!

So you can put large notification_interval and still have quick escalations times, it’s not a problem :)

Under normal circumstances, escalations can be used at any time that a notification could
normally be sent out for the host or service. This “notification time window” is determined
by the notification_period directive in the host or service definition.

You can optionally restrict escalations so that they are only used during specific time periods
by using the escalation_period directive in the host or service escalation definition.
If you use the escalation_period directive to specify time period definition during which the
escalation can be used, the escalation will only be used during that time.
If you do not specify any escalation_period directive, the escalation can be used at any time
within the “notification time window” for the host or service.

Escalated notifications are still subject to the normal time restrictions imposed by the
notification_period directive in a host or service definition, so the timeperiod you specify
in an escalation definition should be a subset of that larger “notification time window”.

If you would like to restrict the escalation definition so that it is only used when the host
or service is in a particular state, you can use the escalation_options directive in the host
or service escalation definition. If you do not use the escalation_options directive, the
escalation can be used when the host or service is in any state.

Legacy definitions: host_escalations and service_escalations based on notification number¶

The Nagios legacy escalations definitions are still managed, but it’s strongly advised to switch
to escalations based on time and call by host/services because it’s far more flexible.