How to Create EPP Rules

This page covers how to create, configure, and manage Event Processing Policy (EPP) rules. For an overview of how the EPP works, see Understanding Event Processing Policy. For a complete reference of filters and actions, see EPP Reference.

Creating a Rule

  1. Open Configuration > Event processing policy

  2. Click Add new rule (new rules are added at the bottom by default)

  3. Configure the filter criteria:

    • Select matching events

    • Select source objects (or select Any for all objects)

    • Set severity filter if needed

    • Add time filters if the rule should only apply during specific hours

  4. Configure actions:

    • Create, resolve, or terminate alarms

    • Execute server actions (send notification, execute command or script, etc.)

  5. Enable Stop event processing on the Action page if subsequent rules should not see the event

  6. Save the policy

Reordering Rules

Rules are reordered by dragging them in the policy editor. The rule context menu also provides Explain, Enable, Disable, Insert above, Insert below, Cut, Copy, Paste, and Delete operations. When reordering, consider:

  • More specific rules should come before more general rules

  • Rules with Stop Processing should be positioned carefully — they prevent all subsequent rules from seeing the event

  • Recovery/deactivation rules typically need their own entries

Common EPP Patterns

Node Down / Node Up

Two rules working together:

Rule 1 — Create alarm on node down: * Event filter: SYS_NODE_DOWN * Action: Create new alarm with key NODE_DOWN_%i, severity Critical

Rule 2 — Terminate alarm on node up: * Event filter: SYS_NODE_UP * Action: Terminate alarms with key NODE_DOWN_%i

Do not set Stop event processing on these rules — it would prevent subsequent notification and escalation rules from seeing the same events.

Threshold Alarm

Rule 1 — Create alarm on threshold: * Event filter: SYS_THRESHOLD_REACHED * Action: Create new alarm with key DC_THRESHOLD_%i_%<dciId>_%<instance>, severity from event

Rule 2 — Terminate alarm on threshold recovery: * Event filter: SYS_THRESHOLD_REARMED * Action: Terminate alarms with key DC_THRESHOLD_%i_%<dciId>_%<instance>

Named parameters are used because positional parameters differ between the two events (the DCI ID is %5 in SYS_THRESHOLD_REACHED but %3 in SYS_THRESHOLD_REARMED). This matches the default policy shipped with NetXMS.

Escalation by Severity

Multiple rules with different actions based on severity:

Rule 1 — Critical events: send SMS + email * Event filter: any * Severity filter: Critical * Actions: Send notification via SMS channel, send notification via email channel

Rule 2 — Major events: send email only * Event filter: any * Severity filter: Major * Actions: Send notification via email channel

Escalation via Timed Outstanding

Alarms can be configured to generate a new event if they remain in Outstanding state for too long. This is configured on the rule’s Alarm page by setting Alarm timeout (in seconds) and selecting the Timeout event to generate. Setting the timeout to 0 disables this feature.

Escalation is built on this mechanism. When an alarm is generated but no operator acknowledges it within a predefined time, a new event can be generated, resulting in additional notifications (email, SMS, instant message) to the operator or their manager. This escalation process can have as many steps as needed.

Alternatively, a single EPP rule can contain multiple actions with different delays. Delay timers are cancelled by another rule when the problem is resolved.

Example — multi-level escalation for node down:

Rule 1 (Node Down with escalation): * Event filter: SYS_NODE_DOWN * Action: Create new alarm with key NODE_DOWN_%i * Action: Send email to on-call engineer (delay: 60, delay timer key: NODEDOWN_NOTIFY_%i) * Action: Send email to support manager (delay: 30m, delay timer key: NODEDOWN_ESCALATE1_%i) * Action: Send email to IT manager (delay: 1h, delay timer key: NODEDOWN_ESCALATE2_%i)

Rule 2 (Node Up cancels escalation): * Event filter: SYS_NODE_UP * Action: Terminate alarms with key NODE_DOWN_%i * Timer Cancellations: NODEDOWN_NOTIFY_%i, NODEDOWN_ESCALATE1_%i, NODEDOWN_ESCALATE2_%i

With this configuration:

  1. After 1 minute, the on-call engineer is notified if the problem still persists

  2. After 30 minutes, the support manager is notified if the problem still persists

  3. After 1 hour, the IT manager is notified if the problem still persists

If the node comes back up before any timer expires, the corresponding notifications are cancelled.

Maintenance Mode and Correlated Events

No rules are needed to suppress alarms for objects in maintenance mode. Events from an object in maintenance are automatically correlated to its maintenance event, and every EPP rule skips correlated events by default — so no alarms are created and no actions run.

To deliberately process events from objects in maintenance (for example, to keep a logging or forwarding rule active during maintenance windows), enable Accept correlated events on the rule’s Condition page. Note that this option applies to all correlated events, not only maintenance — events correlated to a node-down event are affected the same way.

Management Tips

  • Use the rule comment as a descriptive label — it is displayed as the rule header in the editor, and the policy can grow to dozens of rules

  • Use comments to document the purpose and context of complex rules

  • Test new rules in a staging environment before applying to production

  • Back up the EPP before making significant changes — EPP rules are exported via Configuration > Export Configuration

  • Use Disable to temporarily deactivate rules without deleting them

  • Group related rules together (e.g., all notification rules in sequence)