As stated above you need a working way to send messages from the command line. If that doesn't work then you have to fix it first!

You need at least one contact definition like the following:

 define contact {
        contact_name                    jdoe
        host_notifications_enabled      1
        host_notification_period        24x7
        host_notification_options       d,u,r
        host_notification_commands      host-notify-by-email
        service_notifications_enabled   1
        service_notification_period     workhours
        service_notification_options    w,u,c,r
        service_notification_commands   notify-by-email
        email                           jdoe@some.domain.name
        }

The definition contains all required directives and one semi-optional (email).

You need different command definitions for "host-notify-by-email" and "notify-by-email". The definitions shown were taken from the Icinga sample config files. The command line was reformatted.

 # 'notify-host-by-email' command definition
 define command {
        command_name   notify-host-by-email
        command_line   /usr/bin/printf "%b" "***** Icinga *****\n\n \
                       Notification Type: $NOTIFICATIONTYPE$\n \
                       Host: $HOSTNAME$\n \
                       State: $HOSTSTATE$\n \
                       Address: $HOSTADDRESS$\n \
                       Info: $HOSTOUTPUT$\n\n \
                       Date/Time: $LONGDATETIME$\n" \
                       | /usr/bin/mailx -s \
                         "** $NOTIFICATIONTYPE$ Host Alert: \
                         $HOSTNAME$ is $HOSTSTATE$ **" \
                         $CONTACTEMAIL$
        }

 # 'notify-service-by-email' command definition
 define command {
        command_name   notify-service-by-email
        command_line   /usr/bin/printf "%b" "***** Icinga *****\n\n \
                       Notification Type: $NOTIFICATIONTYPE$\n\n \
                       Service: $SERVICEDESC$\n \
                       Host: $HOSTALIAS$\n \
                       Address: $HOSTADDRESS$\n \
                       State: $SERVICESTATE$\n\n \
                       Date/Time: $LONGDATETIME$\n\n \
                       Additional Info:\n\n \
                       $SERVICEOUTPUT$\n" \
                       | /usr/bin/mailx -s \
                         "** $NOTIFICATIONTYPE$ Service Alert: \
                         $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" \
                         $CONTACTEMAIL$
        }

	Note
	Please verify that the programs (printf, mailx) actually exist at the given locations. They may differ between distributions.

There are many macros which can be inserted to add information to the notifications.

	Note
	Several macros have a limited scope, e.g. CONTACT* macros are not available within event handlers.

You are free to write your own notification command adding or removing macros as needed. Just ensure that it contains the information the addressee requires. You may want to write a sophisticated script which checks a database to determine the way a contact can be reached depending on the time the notification is sent (via mail during working hours, additionally via sms during non-working hours, not at all during holidays).

The first service monitors the number of spare discs within a disc shelf. Normally there are two discs available. Having only one should generate a warning, dropping to zero is considered critical. Notifications will be sent at all times, repeating the non-OK state every 60 minutes. John Doe is not part of the admins group so he is specified separately.

The second service monitors the number of users logged in. Exceeding 20 users generates a warning, above 50 users is critical. The shop is closed after working hours and users are logged off automatically after some idle time so there is no need for notifications at other times. Please note that a warning will not send a notification because that is not specified in the notification options! There will be only one notification in case of a non-OK state, even if the state changes between WARNING and CRITICAL.

The last service checks the amount of memory on a machine running batch jobs all the time. Warnings will be generated above 90% RAM usage and if beyond 95% it is considered critical. Sending out messages in a ten minute interval seems to be a good idea but sending them only during workhours might be insufficient. But: although there are a lot of notification options specified the admins group will not get any messages at all! The reason? Please check the meaning of each possible value of "notification_options" for yourself by looking at the object definition of hosts / services.

Has the host/service state already turned into a "hard" state? Check the state looking at the host/service details

Is the macro valid in the context where you are using it?

Is the program to send messages (mail / pager / ...) up and running? Is it possible to send messages from the command line with the account used to run the Icinga process to the address specified in the contact definition? Note: For security reasons the login shell might be disabled so you may have to change that temporarily

Instead of sending messages you can redirect the output to a file by changing "| /usr/bin/mail ..." to something like "> /tmp/notification.log" to verify that all macros are resolved correctly

Check the Icinga log, mail log, and system log for messages

Edit icinga.cfg and change the following directives

 debug_level=32                  # notifications
 debug_verbosity=2               # very detailed
 max_debug_file_size=1000000000  # max 1GB of debug file

Restart Icinga and send a custom notification via the classic UI to check the settings.