Timeperod definitions may contain multiple types of attributes, including weekdays, days of the month, and calendar dates. Different types of attributes have different precedence levels and may override other attributes in your timeperiod definitions. The order of precedence for different types of attributes (in descending order) is as follows:

Host and service definitions have an optional “check_period” attribute that allows you to specify a timeperiod that should be used to restrict when regularly scheduled, active checks of the host or service can be made.

If you do not use the “check_period attribute” to specify a timeperiod, Alignak will be able to schedule active checks of the host or service anytime it needs to. This is essentially a 24x7 monitoring scenario.

Specifying a timeperiod in the “check_period attribute” allows you to restrict the time that Alignak perform regularly scheduled, active checks of the host or service. When Alignak attempts to reschedule a host or service check, it will make sure that the next check falls within a valid time range within the defined timeperiod. If it doesn’t, Alignak will adjust the next check time to coincide with the next “valid” time in the specified timeperiod. This means that the host or service may not get checked again for another hour, day, or week, etc.

On-demand checks and passive checks are not restricted by the timeperiod you specify in the “check_period attribute”. Only regularly scheduled active checks are restricted.

A service’s timeperiod is inherited from its host only if it’s not already defined for the service. In a fresh new default Alignak installation, it is defined to “24x7” in the generic-service service template. If you want that the service notifications are not sent out when the host is outside its notification period, you will have to comment notification_period and/or notification_enabled in the generic-service template.

Unless you have a good reason not to do so, a good practice is to monitor all the hosts and services using timeperiods that cover a 24x7 time range. If you don’t do this, you can run into some problems during the blackout time (times that are not valid in the timeperiod definition):

The status change of the host or service will not appear during the blackout time.

Contacts will mostly likely not get re-notified of problems with a host or service during blackout times.

If a host or service recovers during a blackout time, contacts will not be immediately notified of the recovery.

By specifying a timeperiod in the notification_period attribute of a host or service definition, you can control when Alignak is allowed to send notifications out regarding problems or recoveries for that host or service. When a host notification is about to get sent out, Alignak will make sure that the current time is within a valid range in the “notification_period” timeperiod. If it is a valid time, then Alignak will attempt to notify each contact of the problem or recovery.

You can also use timeperiods to control when notifications can be sent out to individual contacts. By using the service_notification_period and host_notification_period attributes in the contact definition, you’re able to essentially define an “on call” period for each contact. Contacts will only receive host and service notifications in the time frame that are specified in the his/her notification periods.

Service and host notification escalations have an optional escalation_period attribute that allows to specify a timeperiod when the escalation is valid and can be used. If you do not use the escalation_period attribute in an escalation definition, the escalation is considered as permanently valid. If you specify a timeperiod in the escalation_period attribute, Alignak will only use the escalation definition in the time frame that are valid in the timeperiod definition.

Host and service dependencies have an optional dependency_period attribute that allows to specify a timeperiod when the dependendies are valid and can be used. If you do not use the dependency_period attribute in a dependency definition, the dependency can be used at any time. If you specify a timeperiod in the “dependency_period” attribute, Alignak will only use the dependency definition in the time frame that are valid in the timeperiod definition.

Administrators often have to shoulder the burden of answering pagers, cell phone calls, etc. when they least desire them. No one likes to be woken up at 4 am to fix a problem. But its often better to fix the problem in the middle of the night, rather than face the wrath of an unhappy boss when you stroll in at 9 am the next morning ;)

For those lucky admins who have a team of gurus who can help share the responsibility of answering alerts, on-call rotations are often setup. Multiple admins will often alternate taking notifications on weekends, weeknights, holidays, etc.

I’ll show you how you can create timeperiod definitions in a way that can facilitate most on-call notification rotations. These definitions won’t handle human issues that will inevitably crop up (admins calling in sick, swapping shifts, or throwing their pagers into the river), but they will allow you to setup a basic structure that should work the majority of the time.

Two admins - John and Bob - are responsible for responding to Alignak alerts. John receives all notifications for weekdays (and weeknights) - except for holidays - and Bob gets handles notifications during the weekends and holidays. Lucky Bob. Here’s how you can define this type of rotation using timeperiods…

In this scenario John and Bob alternate handling alerts every other week. John handles alerts Sunday through Saturday one week, and Bob handles alerts for the following seven days. This continues in perpetuity.

Define a timeperiod for when John should receive notifications. Assuming today’s date is Sunday, July 29th, 2007 and John is handling notifications this week (starting today), the definition would look like this:

In this scenarios, John handles notifications for all days except those he has off. He has several standing days off each month, as well as some planned vacations. Bob handles notifications when John is on vacation or out of the office.

First, define a timeperiod that contains time ranges for John’s vacation days and days off:

There are a lot of other on-call notification rotation scenarios that you might have. The date exception attribute in the timeperiod definitions is capable of handling most dates and date ranges that you might need to use, so check out the different formats that you can use. If you make a mistake when creating timeperiod definitions, always err on the side of giving someone else more on-call duty time. :-)