An alert in iPM ties together a check (a host or a service) with what should happen when that check moves out of a healthy state — who gets told, how, and under what conditions.
Where alerts come from
Hosts and services added through the Wizard or Auto Discovery often come with sensible default thresholds already attached, so basic alerting can work immediately. It's still worth reviewing these defaults rather than assuming they fit — a threshold that makes sense for a lightly loaded utility server is often wrong for a database server that runs hot by design.
Creating an alert
- Open the host or service you want to alert on.
- Define the condition that should trigger it — see Alert Conditions for how thresholds, duration, and check attempts fit together.
- Assign a contact group and time period, so the right people are notified at the right times — these are set up under Administration (see Initial Configuration if you haven't created them yet).
- Choose how the alert should reach people — see Email Notifications for the most common channel, or the mobile app for push notifications.
- Save, then trigger a test condition if possible (or use a manual test-notification option, where available) to confirm the alert actually reaches the intended contact group before relying on it.
Keep alerts meaningful
An alert only has value if it prompts action. Before adding one, it's worth asking: if this fires at 2 a.m., is it something someone genuinely needs to wake up for? Checks that matter but aren't urgent are often better set to notify during business hours only, or routed to a lower-priority contact group — see Alert Escalation for how to route a single alert differently depending on how long it's been unresolved.
Once alerts are in place, they show up in the dashboard's recent alerts feed and in Alert History, so you have both a real-time and a historical view of everything iPM has flagged.