Email is the most common way iPM reaches people, and getting the configuration and behavior right is what keeps it useful rather than something people quietly filter into a folder they never open.
Before notifications will send
Outbound SMTP needs to be configured under Administration, then System Configuration — see Initial Configuration if this hasn't been set up yet. Send a test notification after configuring it, before relying on it for anything real.
What a notification includes
A typical alert email includes the host or service name, its current status, when the event occurred, and the check's output (the specific detail behind the failure — for example, the actual CPU percentage or the SNMP error encountered). This detail is what lets someone triage from their phone without needing to open the console first.
Re-notification interval
If a problem stays unresolved, iPM can keep sending reminder notifications at a set interval rather than notifying once and going silent. Set this thoughtfully — frequent enough that an ongoing outage isn't forgotten, not so frequent that it becomes noise indistinguishable from a new problem.
Acknowledgement
When someone acknowledges an alert (marking it as being actively worked on), iPM stops sending repeat notifications for that specific problem until it either resolves or the acknowledgement expires. This is the main tool for silencing a known, in-progress issue without having to disable alerting on the host entirely.
Beyond email
For anyone who needs alerts even when they're away from their inbox, the mobile companion app supports push notifications as a parallel channel — useful for on-call staff, without changing anything about how email notifications themselves are configured.