Schedule downtimes for system shutdowns, off-line maintenance, or upgrades without triggering your monitors.
To schedule a monitor downtime in Datadog use the main navigation: Monitors –> Manage Downtime. Then, click the Schedule Downtime button in the upper right.
Search or use the drop-down to choose monitors to silence. If the field is left empty, all monitors are silenced by default. You can also select a scope to constrain your downtime to a specific host, device, or arbitrary tag. Only monitors that have ALL selected scopes are silenced.
Schedule a downtime based on one or more monitor tags. You must select at least one tag with a limit of 32 tags. Each tag can be at most 256 characters long. Only monitors that have ALL selected tags are silenced. You can also select scopes for additional constraints.
If you choose to silence monitors constrained by scope, click Preview affected monitors to see the monitors included. Any monitors created or edited after the downtime is scheduled are automatically included in the downtime if they match the scope.
When constraining a downtime to a simple alert monitor, the
Group scope field can be ignored since a simple alert monitor aggregates over all reporting sources to send a single alert.
If a multi-alert monitor is included, it is only silenced for groups covered by the scope. For example, if a downtime is scoped for
host:X and a multi-alert is triggered on both
host:Y, Datadog generates a monitor notification for
host:Y, but not
The examples below show how
Group scope may be applied to multi-alert monitors.
Example 1: Mute notification for a specific service
service:web-store), enter that group in the
service:web-storeare muted during the scheduled downtime.
service:web-storemuted for this monitor.
service:consul, etc.), you can create an additional downtime per group.
Example 2: Mute notifications for a specific environment of a monitor grouped by
env:dev), enter that group in the
env:devare muted during the scheduled downtime.
env:devand any service related to the
service:web-store), add the additional scope to the downtime.
If a scheduled downtime is based on a common monitor tag and the monitors in scope are multi-alert monitors with one “group by” scope, the
Group scope field can be used to silence a group that the monitors in scope have in common.
Example 1: Two multi alert monitors, each with one “group by” scope, have the
downtime:true monitor tag in common.
service:web-store. Because all the monitor’s groups (by
host) belong to
service:web-store, the result is that all hosts are muted during downtime for this monitor.
Set a one time downtime by entering the start date, time, and time zone. Optionally, set an end date and time.
Recurring downtimes are useful for recurring maintenance windows.
Set a recurring downtime by entering the start date, time, time zone, repeat, and duration. Optionally, specify an end date or number of occurrences.
When a single downtime of a recurring downtime ends, the single downtime is cancelled and a new downtime is created with the same constraints and updated start and end times. Note: The original creator is associated to all the newly created downtimes.
A common use case is to use RRULES to define downtimes on specific days of the month. For example, on the third Monday of each month:
Note: Attributes specifying the duration in RRULE are not supported (for example,
Enter a message to notify your team about this downtime. The message field allows standard markdown formatting and Datadog’s
Notify your team by specifying team members or send the message to a service integration.
The Manage Downtime page displays the list of active and scheduled downtimes. Select a downtime to view details, edit, or delete it. Use the Filter downtimes text box to search your downtimes.
By default this text box searches on the
status parameter of the downtines.
Downtime history is viewable on the Monitor Status page as overlaid on the group transition history, and the Event stream by searching for
tags:audit,downtime, or a specific downtime by ID with
Monitors trigger events when they change between possible states:
NO DATA. When a monitor is muted or has a scheduled downtime, transitions from
RESOLVED to another state do not trigger events or notifications.
If a monitor is in an alert-worthy state (
NO DATA) when downtime expires, the monitor is forced to recover and quickly triggers again if alert conditions are met. This applies to monitors that change state during downtime (such as from
NO DATA), and also to monitors that already have an alert-worthy state when downtime begins.
Example 1: If a monitor is in an alert state before downtime starts and continues for the duration of downtime:
Example 2: If a monitor is in an alert state before a downtime commences and recovers during that downtime:
All alerted states are included on the weekly monitor report even if the monitor is in a downtime.