en	# 11 Maintenance

en	#### Overview You can define maintenance periods for hosts and host groups in Zabbix. Furthermore, it is possible to define maintenance only for a single trigger (or subset of triggers) by specifying trigger tags. In this case maintenance will be activated only for those triggers; all other triggers of the host or host group will not be in maintenance. There are two maintenance types - with data collection and with no data collection. During a maintenance "with data collection" triggers are processed as usual and events are created when required. However, problem escalations are paused for hosts/triggers in maintenance, if the *Pause operations for suppressed problems* option is checked in action configuration. In this case, escalation steps that may include sending notifications or remote commands will be ignored for as long as the maintenance period lasts. Note that problem recovery and update operations are not suppressed during maintenance, only escalations. For example, if escalation steps are scheduled at 0, 30 and 60 minutes after a problem start, and there is a half-hour long maintenance lasting from 10 minutes to 40 minutes after a real problem arises, steps two and three will be executed a half-hour later, or at 60 minutes and 90 minutes (providing the problem still exists). Similarly, if a problem arises during the maintenance, the escalation will start after the maintenance. To receive problem notifications during the maintenance normally (without delay), you have to uncheck the *Pause operations for suppressed problems* option in action configuration. ::: noteclassic If at least one host (used in the trigger expression) is not in maintenance mode, Zabbix will send a problem notification. ::: Zabbix server must be running during maintenance. Maintenances are recalculated every minute or as soon as the configuration cache is reloaded if there are changes to the maintenance period. Timer processes check if host status must be changed to/from maintenance at 0 seconds of every minute. Additionally, every second the timer process checks if any maintenances must be started/stopped based on whether there are changes to the [maintenance periods] after the configuration update. Thus the speed of starting/stopping maintenance periods depends on the configuration [update interval](/manual/appendix/config/zabbix_server#cacheupdatefrequency) (10 seconds by default). Note that maintenance period changes do not include *Active since/Active till* settings. Also, if a host/host group is added to an existing active maintenance period, the changes will only be activated by the timer process at the start of next minute. Note that when a host enters maintenance, Zabbix server timer processes will read all open problems to check if it is required to suppress those. This may have a performance impact if there are many open problems. Zabbix server will also read all open problems upon startup, even if there are no maintenances configured at the time. Note that the Zabbix server (or proxy) always collects data regardless of the maintenance type (including "no data" maintenance). The data is later ignored by the server if 'no data collection' is set. When "no data" maintenance ends, triggers using nodata() function will not fire before the next check during the period they are checking. If a log item is added while a host is in maintenance and the maintenance ends, only new logfile entries since the end of the maintenance will be gathered. If a timestamped value is sent for a host that is in a “no data” maintenance type (e.g. using [Zabbix sender](/manpages/zabbix_sender)) then this value will be dropped however it is possible to send a timestamped value in for an expired maintenance period and it will be accepted. If maintenance period, hosts, groups or tags are changed by the user, the changes will only take effect after configuration cache synchronization.

en	#### Configuration To configure a maintenance period: 1. Go to: *Data collection > Maintenance*. 2. Click on *Create maintenance period* (or on the name of an existing maintenance period). 3. Enter maintenance parameters in the form. ![](../../assets/en/manual/maintenance/maintenance.png){width="600"} All mandatory input fields are marked with a red asterisk. |Parameter|Description| |--|--------| |*Name*|Name of the maintenance period.| |*Maintenance type*|Two types of maintenance can be set:<br>**With data collection** - data will be collected by the server during maintenance, triggers will be processed;<br>**No data collection** - data will not be collected by the server during maintenance.<br>See [Effect of maintenance periods](/manual/web_interface/frontend_sections/reports/availability#effect-of-maintenance-periods) for how each type affects the availability report.| |*Active since*|The date and time when executing maintenance periods becomes active.<br>*Note:* Setting this time alone does not activate a maintenance period; maintenance periods must be configured in *Periods* (see below).| |*Active till*|The date and time when executing maintenance periods stops being active.| |*Periods*|This block allows you to define the exact days and hours when the maintenance takes place. Clicking on ![](../../assets/en/manual/maintenance/add_link.png) opens a popup window with a flexible *Maintenance period* form where you can define maintenance schedule. See [Maintenance periods](#maintenance_periods) for a detailed description.| |*Host groups*|Select host groups that the maintenance will be activated for. The maintenance will be activated for all hosts from the specified host group(s). This field is auto-complete, so starting to type in it will display a dropdown of all available host groups.<br>Specifying a parent host group implicitly selects all nested host groups. Thus the maintenance will also be activated on hosts from nested groups.| |*Hosts*|Select hosts that the maintenance will be activated for. This field is auto-complete, so starting to type in it will display a dropdown of all available hosts.<br>| |*Tags*|Specify tags to [suppress problems](/manual/acknowledgment/suppression) with matching tags on hosts in maintenance.<br>Several conditions can be set. Tag name matching is always case-sensitive.<br><br>There are two operators available for each condition:<br>**Contains** - include the specified tag names where the tag values contain the entered string (substring match, case-sensitive);<br>**Equals** - include the specified tag names and values (case-sensitive).<br><br>There are two calculation types for conditions:<br>**And/Or** - all conditions must be met, conditions having the same tag name will be grouped by the Or condition;<br>**Or** - enough if one condition is met.<br><br>Tags can be specified only if *With data collection* mode is selected.| |*Description*|Description of maintenance period.|

en	##### Maintenance periods The maintenance period window is for scheduling time for a recurring or a one-time maintenance. The form is dynamic with available fields changing based on the *Period type* selected. ![](../../assets/en/manual/maintenance/maintenance_period.png){width="600"} |Period type|Description| |--|--------| |*One time only*|Configure a one time only maintenance period:<br>*Date* - date and time of the maintenance period;<br>*Maintenance period length* - for how long the maintenance will be active.| |*Daily*|Configure a daily maintenance period:<br>*Every day(s)* - maintenance frequency (1 - *(default)* every day, 2 - every two days, etc.);<br>*At (hour:minute)* - time of the day when maintenance starts;<br>*Maintenance period length* - for how long the maintenance will be active.<br><br>When *Every day(s)* parameter is greater than "1", the starting day is the day that the *Active since* time falls on. Examples:<br>- if *Active since* is set to "2021-01-01 12:00", *Every day(s)* is set to "2", and *At (hour:minute)* is set to "23:00", then the first maintenance period will start on January 1 at 23:00, while the second maintenance period will start on January 3 at 23:00;<br>- if *Active since* is set to "2021-01-01 12:00", *Every day(s)* is set to "2", and *At (hour:minute)* is set to "01:00", then the first maintenance period will start on January 3 at 01:00, while the second maintenance period will start on January 5 at 01:00.| |*Weekly*|Configure a weekly maintenance period:<br>*Every week(s)* - maintenance frequency (1 - *(default)* every week, 2 - every two weeks, etc.);<br>*Day of week* - on which day the maintenance should take place;<br>*At (hour:minute)* - time of the day when maintenance starts;<br>*Maintenance period length* - for how long the maintenance will be active.<br><br>When *Every week(s)* parameter is greater than "1", the starting week is the week that the *Active since* time falls on. For examples, see parameter *Daily* description above.| |*Monthly*|Configure a monthly maintenance period:<br>*Month* - select all months during which the regular maintenance is carried out;<br>*Date: **Day of month*** - select this option if the maintenance should take place on the same date each month (for example, every 1st day of the month), and then select the required day in the field *Day of month* that appears;<br>*Date: **Day of week*** - select this option if the maintenance should take place only on certain days (for example, every first Monday of the month), then select (in the drop-down) the required week of the month (first, second, third, fourth, or last), and then mark the checkboxes for maintenance day(s);<br>*At (hour:minute)* - time of the day when maintenance starts;<br>*Maintenance period length* - for how long the maintenance will be active.|

en	::: noteimportant When creating a maintenance period, the [time zone](/manual/web_interface/time_zone) of the user who creates it is used. However, when recurring maintenance periods (*Daily*, *Weekly*, *Monthly*) are scheduled, the time zone of the Zabbix server is used. To ensure predictable behavior of recurring maintenance periods, it is required to use a common time zone for all parts of Zabbix. :::

en	When done, press *Add* to add the maintenance period to the *Periods* block. Note that Daylight Saving Time (DST) changes do not affect how long the maintenance will be. For example, let's say that we have a two-hour maintenance configured that usually starts at 01:00 and finishes at 03:00: - if after one hour of maintenance (at 02:00) a DST change happens and current time changes from 02:00 to 03:00, the maintenance will continue for one more hour (till 04:00); - if after two hours of maintenance (at 03:00) a DST change happens and current time changes from 03:00 to 02:00, the maintenance will stop, because two hours have passed; - if a maintenance period starts during the hour that is skipped by a DST change, then the maintenance will not start. If a maintenance period is set to "1 day" (the actual period of the maintenance is 24 hours, since Zabbix calculates days in hours), starts at 00:00 and finishes at 00:00 the next day: - the maintenance will stop at 01:00 the next day if current time changes forward one hour; - the maintenance will stop at 23:00 that day if current time changes back one hour.

en	#### Display

en	##### Displaying hosts in maintenance An orange wrench icon ![](../../assets/en/manual/web_interface/frontend_sections/configuration/maintenance_wrench_icon.png) next to the host name indicates that this host is in maintenance in: - *Dashboards* - *Monitoring > Problems* - *Inventory > Hosts > Host inventory details* - *Data collection > Hosts* (See 'Status' column) ![](../../assets/en/manual/maintenance/maintenance_icon.png) Maintenance details are displayed when the mouse pointer is positioned over the icon. Additionally, hosts in maintenance get an orange background in *Monitoring > Maps*.

en	##### Displaying suppressed problems Normally problems for hosts in maintenance are suppressed, i.e. not displayed in the frontend. However, it is also possible to configure that suppressed problems are shown, by selecting the *Show suppressed problems* option in these locations: - *Dashboards* (in *Problem hosts*, *Problems*, *Problems by severity*, *Trigger overview* widget configuration) - *Monitoring* > *Problems* (in the filter) - *Monitoring* > *Maps* (in map configuration) - Global [notifications](/manual/web_interface/user_profile/global_notifications) (in user profile configuration) When suppressed problems are displayed, the following icon is displayed: ![](../../assets/en/manual/web_interface/icon_suppressed.png). Rolling a mouse over the icon displays more details. ![](../../assets/en/manual/web_interface/info_suppressed2.png)

en	#### Calculation of queues during maintenance Queues displayed in the Zabbix frontend ([Administration > Queue](/manual/web_interface/frontend_sections/administration/queue)) are calculated by the Zabbix server. They do not include items under maintenance with no data collection—queue length is always zero for these items even when their values are delayed. Delayed items in maintenance with data collection are still counted in the queue. The Zabbix [proxy](/manual/concepts/proxy) is not aware of maintenance periods because there is no synchronization of maintenance configuration between the Zabbix server and proxy. Internal checks calculated on Zabbix proxies (for example, [`zabbix[queue,,]`](/manual/config/items/itemtypes/internal#queue) and [`zabbix[stats,,,queue,,]`](/manual/config/items/itemtypes/internal#stats.queue)) report delayed items regardless of the maintenance status on the Zabbix server. As a result, different queue lengths may be reported for the same items in maintenance with no data collection by the Zabbix frontend and by internal checks on Zabbix proxies.