1 ## <a id="volatile-services"></a> Volatile Services
3 By default all services remain in a non-volatile state. When a problem
4 occurs, the `SOFT` state applies and once `max_check_attempts` attribute
5 is reached with the check counter, a `HARD` state transition happens.
6 Notifications are only triggered by `HARD` state changes and are then
7 re-sent defined by the `notification_interval` attribute.
9 It may be reasonable to have a volatile service which stays in a `HARD`
10 state type if the service stays in a `NOT-OK` state. That way each
11 service recheck will automatically trigger a notification unless the
12 service is acknowledged or in a scheduled downtime.