Event rules and alerts
Quick answer
Turn monitoring noise into actionable alerts with event rules, binding, thresholds and alert management.
Key takeaways
- Events are raw, alerts are the working record
- CI binding is what makes impact and automation possible
- Thresholds and correlation are how you cut noise
- Not every alert deserves an incident
From event to alert
Connectors pull events from monitoring tools. Event rules parse them, bind them to a CI, set severity and decide whether they create an alert. Alerts are the working unit, events are raw material.
Binding to a CI
An alert without a CI cannot drive impact or automation. Binding uses the fields in the event payload against CMDB identifiers. When binding fails consistently, the fix is usually in the CMDB, not in the rule.
Reducing noise
Alert management earns its keep by not waking people up.
- Use threshold rules so five flaps in a minute become one alert
- Group related alerts with alert correlation rules
- Set an auto close so alerts clear when the source clears
- Route only what is actionable to incident creation, everything else stays as an alert
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
What connects an alert to impacted services?
- A. Severity
- B. CI binding
- C. Alert age
- D. Connector type
Show answer
B. CI binding
Binding to a CI lets the platform calculate service impact.
Which rule type suppresses flapping alerts?
- A. Threshold rule
- B. Transform map
- C. Assignment rule
- D. Data policy
Show answer
A. Threshold rule
Threshold rules require a count within a window before an alert is raised.