An alert condition is the specific rule that decides when a check has actually failed — and getting this right is what separates useful alerting from a flood of noise nobody trusts.
Thresholds
The starting point for most conditions is the same Warning/Critical threshold model covered throughout Performance Monitoring — CPU above 90%, disk above 95%, and so on. A condition is built on top of one of these thresholds, but adds the logic for exactly when it should actually notify someone.
Check attempts (soft vs. hard state)
A single failed check is often just noise — a brief network blip, a momentary spike. iPM (like most monitoring platforms) supports requiring a check to fail a set number of consecutive times before it's treated as a real problem and an alert fires. The check moves through a "soft" failing state during these attempts, and only becomes "hard" (and notification-worthy) once it's failed consistently. Raising the required attempt count reduces false alarms at the cost of slightly slower detection — a reasonable trade-off for most checks, and less appropriate for the handful of things where you want to know about the very first failure.
Duration-based conditions
For metrics that naturally spike briefly (CPU is the classic example), a condition can require the threshold to be breached continuously for a set duration, not just at one polling interval. This is usually the better tool for noisy metrics, compared to just increasing the check-attempt count.
Flapping
A check that repeatedly flips between OK and a failing state (rather than settling into one or the other) is described as flapping. Flapping detection suppresses the resulting flood of repeat notifications, and can instead raise a single "this check is flapping" alert, which is almost always more useful than dozens of alternating up/down alerts for the same underlying instability.
Combine conditions deliberately
The right combination — threshold, check attempts, and duration — depends entirely on what's being monitored. A one-off web request failure and a sustained memory leak deserve very different alerting logic, even though both might ultimately use the same underlying check type.