Maintenance Windows¶
Feature Availability
This is a paid feature that is not available for every user. Access to dynamic rules starts with the Essential plan.
A maintenance window is designed to suppress monitoring notifications during a defined period of time.
While a maintenance window is active, no notifications will be sent out for an affected monitor, no matter if it's for a direct contact or for a contact that is included in a dynamic rule. However, it's important to understand that monitoring will continue for affected hosts. The host will be shown as unavailable, if the monitoring agents are considering the target down.
Types¶
There are two different types of maintenance windows.
One-Off¶
A one-off maintenance window is defined for a certain date, time and duration in the future. The window becomes active when that date and time is reached and ends after the defined duration. After a one-off maintenance window is over, it can no longer be modified. Before the start of a maintenance window, it can still be modified (e.g. moved to another day).
Example Use Case
You are receiving an unplanned maintenance notification from a vendor happening next week. You are aware of any issues that might arise in that time want to make sure that your engineering team isn't being bothered with the expected notifications and to not waste any phone notifications for the calendar month.
Recurring¶
A recurring maintenance window can be defined to start
- every day,
- every week on certain weekdays or
- every month on certain days of the month
at a certain time for a certain duration. Experienced users can also use a crontab expression to define the recurring maintenance window.
Example Use Case
Your IT department runs automatic updates always on the first Wednesday of a month. By utilising the crontab expression, you can create a recurring maintenance window that ensures that no notifications are being sent out during that automatic update window for the affected hosts.
Start Time¶
Unless you're using a crontab expression to define a recurring maintenance window, all other kind of maintenance windows require you to provide a UTC offset when specifying when the maintenance window should start.
This is especially helpful if you're getting maintenance notifications from vendors from different locations across the world. It eliminates the need to calculate with timezones and offsets and helps to avoid confusion.
Timezones and Offsets
Keep in mind that a timezone and an offset are not the same thing. A timezone's UTC offset can change over the course of a year (during summer and winter time). Argus requires you to provide an offset.
Affected Monitors¶
You might notice that while creating a maintenance window, you don't specify which monitors should be affected.
Direct Affection¶
In order to tell Argus that a certain maintenance window should suppress the notifications for a certain monitor, you can directly associate them together.
This is the easiest way, but also the one with the least amount of flexibility. Use this mode for one-off maintenances that only affect a very limited amount of monitors.
Affection by Tag¶
This is the recommended way of working with maintenance windows and monitors.
You can add one or more tags to a maintenance window. The maintenance window then dynamically affects all monitors that are tagged with at least one of the defined tags as well. With other words, the list of affected tags can be considered concatenated with a logical OR expression.
Whether a maintenance window is affecting a monitor or not, is being evaluated in the second when the system is about to dispatch a notification.
This is the most flexible way of handling maintenance windows, because it allows you to define a maintenance window once and never touch it again, even if you're adding hosts that should be affected by it in the future.
Evaluation¶
Whether a maintenance window is suppressing the notifications for a monitor or not is being evaluated at the time when the system is about to dispatch a notification.
Pitfall
If you are using delayed notifications, the decision whether a notification is being dispatched or not is being made in the second where the system detects a notifiable event and not after the delay is over.
If a notification is configured to be sent 5 minutes after a monitor goes down and said monitor is considered unavailable one minute before a maintenance window goes into effect, the notification is still being dispatched 4 minutes into the maintenance window, because at the time of the evaluation, it wasn't affecting the monitor in question.
Pausing¶
You can pause and resume a maintenance window. This can be manually done on the maintenance window overview page as well as on a maintenance window's detail page.
While a maintenance window is being paused, it does not affect monitors. Thus, monitors that become unavailable while a paused maintenance window is into effect, will still cause monitoring notifications to be dispatched to your contacts.
Resuming a maintenance window makes them work as expected again.