Alarms

Alarms represent active problems that require attention. They are created by the Event Processing Policy when events match rules configured with alarm generation actions.

Alarm Lifecycle

An alarm progresses through defined states from creation to termination:

  1. Outstanding — alarm has been created, no operator has acknowledged it

  2. Acknowledged — an operator has acknowledged the alarm but it is not yet resolved

  3. Resolved — the condition has cleared (automatically or manually), awaiting termination

  4. Terminated — alarm is closed and moved to history

For a complete state transition table, alarm properties, severity levels, and configuration variables, see Alarm Configuration Reference.

Sticky and Timed Acknowledgement

By default, if a new event with the same alarm key arrives while the alarm is acknowledged, the alarm returns to the Outstanding state. Sticky acknowledgement prevents this — the alarm stays acknowledged even when new matching events arrive. Use Sticky acknowledge instead of the regular acknowledge operation.

Sticky acknowledgement can also be time-limited (timed acknowledgement). The Sticky acknowledge for menu offers preset durations (1 hour, 4 hours, 24 hours, 48 hours) and Other…​ for a custom duration. When the timeout expires, the alarm returns to the Outstanding state and the timeout event configured in the EPP rule that created the alarm is generated (default: SYS_ALARM_TIMEOUT). This is useful for temporarily silencing an alarm during planned work. Timed acknowledgement is controlled by the Alarms.EnableTimedAck server configuration variable (enabled by default; changing it requires a server restart). When disabled, the timed acknowledgement options are hidden in the management client.

Alarm Properties

Each alarm has properties including ID, key, state, severity, source, message, timestamps, and related events. See Alarm Properties Reference for the full list.

Alarm Severity

Alarm severity is inherited from the triggering event by default but can be overridden in the EPP rule.

The severity determines:

  • Visual presentation in the management client (color coding)

  • Sorting and filtering in alarm views

Severity and Object Status

Active alarms raise the status of their source object: the object’s status is the maximum of its calculated status and the severity of its most critical active alarm. Resolving or terminating an alarm triggers a status recalculation. The resulting status then propagates up the object tree according to the settings on each object’s Status Calculation properties page:

  • Status propagation — how this object’s status is passed to its parents: Default, Unchanged, Fixed value, Relative with offset, or Severity based (per-status mapping)

  • Status calculation — how an object computes its own status from its children: Default, Most critical, Single threshold, or Multiple thresholds

A container therefore reflects alarms on its child objects through normal status calculation.

Alarm Views

The Alarms perspective in the management client displays all active alarms; each object also has an Alarms view showing alarms for that object and its children.

Alarm Operations

From the alarm views, operators can:

  • Acknowledge, sticky acknowledge, or sticky acknowledge for a limited time

  • Resolve and terminate alarms

  • Create an incident from the alarm

  • Go to the source object or to the related DCI

  • Ask the AI assistant about the alarm (Ask AI assistant…​)

  • Create a helpdesk ticket or unlink the alarm from a helpdesk ticket

Related events are shown, and comments are added, in the alarm details view.

See Alarm Operations Reference for details on each operation.

Alarm Categories

Alarms can be assigned to categories for organization and access control.

Configuring Categories

  1. Open Configuration > Alarm Categories

  2. Create categories (e.g., "Network", "Server", "Application", "Security")

  3. Assign categories in EPP rules (alarm generation action)

  4. Configure user access rights per category

Category-based Access Control

Each alarm category has an access control list — a flat list of users and groups. Users have access to alarms in a category if they (or a group they belong to) are on the category’s list; there are no separate view, acknowledge, or terminate grants. Users with the View all alarm categories system access right (and the built-in system user) bypass category access control and see alarms in all categories.

This enables scenarios where network operators see only network alarms, while application teams see only application alarms.

Alarm Auto-Resolution and Auto-Termination

An EPP rule can automatically resolve or terminate alarms whose key matches the key configured in the rule. This is the standard pattern for alarm correlation. In the shipped default policy, the SYS_NODE_UP event terminates alarms created by SYS_NODE_DOWN using the same alarm key. A rule can optionally treat the termination key as a regular expression, closing all alarms whose keys match it.

Resolved alarms can additionally be terminated automatically after a timeout configured with the Alarms.ResolveExpirationTime server configuration variable (in seconds, default 0 = disabled). Automatic termination is skipped while a helpdesk ticket is open for the alarm.

See Alarm Configuration Variables for all alarm-related server settings.

Alarm Repeat Count

When a new event matches the key of an already-active alarm, the alarm is not duplicated. Instead, the repeat count is incremented, the last change timestamp is updated, and the new event is added to the alarm’s related events list.

This prevents alarm flooding when a problem generates repeated events.

Alarm Comments

Operators can attach comments to alarms to document troubleshooting progress, root cause analysis, or handoff notes.

Each comment records:

  • The user who last changed the comment

  • The time of the last change

  • Comment text

Editing a comment overwrites this metadata — the original author and creation time are not preserved. Comments can be edited or deleted at any time, remain attached to the alarm through its lifecycle, and are deleted together with the alarm when it is purged by the housekeeper. The Alarms log does not display comments.

Alarm History

Terminated alarms are not moved anywhere — they remain in the alarm table flagged as terminated until purged by the housekeeper. The Alarms log in the Logs perspective of the management client shows both active and terminated alarms.

Terminated alarms are retained for auditing and trend analysis. Retention is controlled by the server configuration variable Alarms.HistoryRetentionTime (in days, default: 180).

Alarm Summary Emails

NetXMS can send scheduled emails containing a summary of all currently active alarms. Summary emails are sent through the notification channel named by the DefaultNotificationChannel.SMTP.Html server configuration variable (default: SMTP-HTML).

To enable alarm summary emails, configure the Alarms.SummaryEmail.* server configuration variables. See Alarm Configuration Variables for details.

Alarm Sound Notifications

The desktop management client can play sound notifications when new alarms arrive. Sounds are configured on the separate Alarm sounds preference page: a melody can be assigned to each severity, plus a reminder sound slot. There is no minimum-severity setting — leave a severity’s melody empty to keep that severity silent.

Alarm Status Flow Customization

The default alarm flow (Outstanding → Acknowledged → Resolved → Terminated) can be customized with the Alarms.StrictStatusFlow server configuration variable (default: 0 = disabled, alarms can be terminated without going through the Resolved state). See Alarm Configuration Variables.

Helpdesk Integration

Alarms can be linked to external helpdesk systems (JIRA, ServiceNow, etc.) via the helpdesk integration API.

When configured:

  • Alarms can be escalated to helpdesk tickets from the alarm views

  • Ticket status changes can update alarm state

  • Helpdesk ticket reference is displayed in the alarm properties

See Helpdesk Integration for configuration details.

Next Steps