We discussed hosts and host group maintenance in Chapter 5, Managing Hosts, Users, and Permissions. That allowed us to stop alerting, but when doing so, the smallest entity the maintenance could affect was a host; we could not create a maintenance for a specific trigger without the use of tags. While this is slightly different functionally, we could limit the time for which a trigger is active on the trigger level, too. To do so, we can use several of those time-based trigger functions. Taking our CPU load trigger as an example, we could completely ignore it on Mondays (perhaps there's some heavy reporting done on Mondays):

{A test host:system.cpu.load.avg(180)}>1 and 
{A test host:system.cpu.load.dayofweek()}<>1 

The dayofweek() function returns a number with Monday starting at 1, and the previous expression works unless the returned value is 1. We have to append a trigger function to an item even if it does not take item values at all, such as in this case. It is quite counter-intuitive seeing the dayofweek() function after the CPU load item, but it's a best practice to reuse the same item.

We could also make this trigger ignore weekend mornings:

{A test host:system.cpu.load.avg(180)}>1 and 
{A test host:system.cpu.load.dayofweek()}>5 and 
{A test host:system.cpu.load.time()}<100000 

Here, we are checking for the day value to be above 5 (with 6 and 7 being Saturday and Sunday). Additionally, the trigger time() function is being used. This function returns the time in HH:MM:SS format, so our comparison makes sure it is not 10:00:00 yet.

Note that this method completely prevents the trigger from firing, so we won't get alerts, won't see the trigger on the frontend, and there won't be any events being generated.

We will also discuss a way to limit alerts themselves based on time in Chapter 7, Acting Upon Monitored Conditions.