## <a id="downtimes"></a> 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.

### <a id="fixed-flexible-downtimes"></a> 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!).

### <a id="scheduling-downtime"></a> 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`.

### <a id="triggered-downtimes"></a> 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.

### <a id="recurring-downtimes"></a> Recurring Downtimes

[ScheduledDowntime objects](#objecttype-scheduleddowntime) 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" inherits "generic-host" {
      ...
      services["load"] = {
        templates = [ "generic-service" ],

        check_command = "load",

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