icinga2/doc/6.01-downtimes.md

Downtimes

Downtimes can be scheduled for planned server maintenance or any other targetted service outage you are aware of in advance.

Downtimes will suppress any notifications, and may trigger other downtimes too. If the downtime was set by accident, or the duration exceeds the maintenance, you can manually cancel the downtime. Planned downtimes will also be taken into account for SLA reporting tools calculating the SLAs based on the state and downtime history.

Note

Downtimes may overlap with their start and end times. If there are multiple downtimes triggered for one object, the overall downtime depth will be more than 1. This is useful when you want to extend your maintenance window taking longer than expected.

Fixed and Flexible Downtimes

A fixed downtime will be activated at the defined start time, and removed at the end time. During this time window the service state will change to NOT-OK and then actually trigger the downtime. Notifications are suppressed and the downtime depth is incremented.

Common scenarios are a planned distribution upgrade on your linux servers, or database updates in your warehouse. The customer knows about a fixed downtime window between 23:00 and 24:00. After 24:00 all problems should be alerted again. Solution is simple - schedule a fixed downtime starting at 23:00 and ending at 24:00.

Unlike a fixed downtime, a flexible downtime end does not necessarily happen at the provided end time. Instead the downtime will be triggered by the state change in the time span defined by start and end time, but then last a defined duration in minutes.

Imagine the following scenario: Your service is frequently polled by users trying to grab free deleted domains for immediate registration. Between 07:30 and 08:00 the impact will hit for 15 minutes and generate a network outage visible to the monitoring. The service is still alive, but answering too slow to Icinga 2 service checks. For that reason, you may want to schedule a downtime between 07:30 and 08:00 with a duration of 15 minutes. The downtime will then last from its trigger time until the duration is over. After that, the downtime is removed (may happen before or after the actual end time!).

Scheduling a downtime

This can either happen through a web interface (Icinga 1.x Classic UI or Web) or by using the external command pipe provided by the ExternalCommandListener configuration.

Fixed downtimes require a start and end time (a duration will be ignored). Flexible downtimes need a start and end time for the time span, and a duration independent from that time span.

Note

Modern web interfaces treat services in a downtime as handled.

Triggered Downtimes

This is optional when scheduling a downtime. If there is already a downtime scheduled for a future maintenance, the current downtime can be triggered by that downtime. This renders useful if you have scheduled a host downtime and are now scheduling a child host's downtime getting triggered by the parent downtime on NOT-OK state change.

Recurring Downtimes

ScheduledDowntime objects can be used to set up recurring downtimes for services.

Example:

template ScheduledDowntime "backup-downtime" {
  author = "icingaadmin",
  comment = "Scheduled downtime for backup",

  ranges = {
    monday = "02:00-03:00",
    tuesday = "02:00-03:00",
    wednesday = "02:00-03:00",
    thursday = "02:00-03:00",
    friday = "02:00-03:00",
    saturday = "02:00-03:00",
    sunday = "02:00-03:00"
  }
}

object Host "localhost" {
  import "generic-host",

  ...
  services["load"] = {
    templates = [ "generic-service" ],

    check_command = "load",

    scheduled_downtimes["backup"] = {
      templates = [ "backup-downtime" ]
    }
  },
}