You should have a Nagios Core 4.0 or newer server, with at least one host configured already. We'll use the example of sparta.example.net, a host defined in its own file, which we'll configure to send only the DOWN and RECOVERY notifications, ignoring other notifications such as WARNING and UNKNOWN. It will send the notifications to an existing contact called john; we'll ensure that this contact is configured to receive those notifications.

We can configure the notification types for our host as follows:

With this done, the notifications sent when the host enters the DOWN state and also when it recovers into OK state should be sent to the contact. But no other notifications about the host (such as UNREACHABLE or DOWNTIMESTART notifications) should be sent about the sparta.example.net host to the contact john.

The kind of notifications a host should produce is defined in its notification_options directive and the kind of notifications that a defined contact should receive is configured in its host_notification_options directive. Both take the form of comma-separated values.

The valid values for the notification_options directive for host objects are:

For example, we might define a host that should only send notifications when entering the DOWN or UP states, but ignore the notification events for UNREACHABLE or flapping, as follows:

define host {
    ...
    notification_options d,r
}

For service objects, the valid directives are slightly different:

For example, for a host that should send notifications for all of these events except for the flapping and scheduled downtime states, we might define:

define service {
    ...
    notification_options  w,u,c,r
}

All of the preceding values can be used in contact object definitions to restrict the service notifications that a particular contact should receive, through the service_notification_options directive:

define contact {
    ...
    service_notifications_enabled  1
    service_notification_options   w,u,c,r
}

Unless we have a specific reason for particular contacts not to accept notifications of a particular kind, it's good practice to configure the contacts to receive all the notifications that they are sent, by including all the flags in both the directives for the contact:

define contact {
    ...
    host_notification_options     d,u,r,f,s
    service_notification_options  w,u,c,r,f,s
}

This means that the contact will process any notification dispatched to it and we can instead restrict the kinds of notifications that are sent out by the hosts and services for which this is the delegated contact. With new configurations, it is generally better to start by sending too much information and then removing the unnecessary notification flags if appropriate, rather than potentially missing important messages because they're never sent.

If we intend to do this for all of our contacts, it may be appropriate to include these directives as part of a contact template and inherit from it using the use directive. The generic-contact contact template included with the default configuration may be suitable.