Notifications

NetXMS can send notifications through multiple channels when events occur or alarms are created. Notification delivery is configured through notification channels and EPP action rules.

Notification Architecture

The notification flow in NetXMS:

  1. An event is generated

  2. The EPP matches the event to a rule

  3. The rule executes an action configured to send a notification

  4. The action specifies the notification channel and recipient

  5. The notification channel delivers the message

Notification Channels

A notification channel defines the delivery method and connection parameters for sending messages.

Channel Status

Once a notification channel is created, it appears in the channel list with a status indicator:

  • Green — driver initialization was successful

  • Red — driver initialization failed

The channel list has the following columns:

  • Name — channel name

  • Description — channel description

  • Driver — driver used by the channel

  • Messages — number of messages sent through the channel

  • Failures — number of failed send attempts

  • Digested — number of messages combined by message digesting

  • Queue — number of messages currently waiting in the channel’s queue

  • Status — result of the last send attempt

  • Error message — details about initialization or sending failures

Messages waiting in a channel’s queue can be discarded with Clear queue in the channel’s context menu.

Configuring Notification Channels

  1. Open Configuration > Notification Channels

  2. Click New…​

  3. Select the driver

  4. Configure driver-specific settings in the Driver configuration field

  5. Test the channel with Send notification…​

For driver-specific configuration parameters, see Notification Channel Driver Reference.

Delivery Behavior

Notification channels implement rate limiting (both per channel and per recipient), message digesting (combining multiple messages into a single one), and automatic retry of failed send attempts. The maximum number of retries is controlled by the NotificationChannels.MaxRetryCount server configuration variable (default 30).

Recipients

The Recipient field of a notification action is a plain text string. Macro substitution is applied to it, then the result is split on semicolons (with surrounding whitespace trimmed) and the message is sent once per recipient — the server does not interpret recipients as user or group names and does not look up addresses anywhere. The expected format of each recipient depends on the driver: an email address, a phone number, a Telegram chat ID, and so on.

User Contact Information

User accounts in NetXMS have Email and Phone number fields (open Configuration > Users and groups and edit the user), and additional channel-specific addresses can be stored in custom attributes. Nothing in the notification delivery path reads these fields automatically — they are only accessible from NXSL scripts. To deliver a notification to an address stored in a user’s profile, use a %[script] macro in the Recipient field and return the address from the script.

Notification Actions

Notifications are triggered by EPP actions. To set up notification delivery:

  1. Create a notification channel (as described above)

  2. Create an action of type Send Notification (see Actions)

  3. In the action, select the notification channel and specify recipients

  4. Attach the action to an EPP rule

Message Templates

Notification messages use templates with macro substitution. All macros from the Action Macro Reference are available in notification templates.

Commonly used macros:

  • %n — source object name

  • %a — source IP address

  • %s — event severity code as number (0-4)

  • %S — event severity code as text

  • %m — event message text

  • %N — event name

  • %A — alarm message text (when triggered from alarm-generating rule)

  • %t — timestamp

  • %1 through %99 — positional event parameters

  • %<name> — named event parameter

  • %{name} — custom attribute of the source object

Example email template:

Subject: [{product-name}] %S alarm on %n
Body:
Alarm: %A
Event: %N
Source: %n (%a)
Severity: %S
Time: %t

Notification Routing by Schedule

Different notification targets can be used for different times by combining EPP time filters with separate notification actions:

  • Rule 1 (business hours, Mon-Fri 08:00-18:00): send to on-call team email

  • Rule 2 (off-hours): send to on-call SMS + manager email

See Event Processing Policy for details on time filters.

Notification Logging

Each notification message is recorded in the notification log with a success or failure flag — one record per message, written after all retry attempts. The log does not contain error details; delivery errors surface in the channel’s Error message column and through the SYS_NOTIFICATION_FAILURE event. Messages discarded because the channel queue is full (NotificationChannels.MaxQueueSize server configuration variable, default 500) are not logged at all. The log is available at Logs > Notifications; viewing it requires the "View notification log" system access right.

Executions of all action types — including notifications, with channel, recipient, and subject — are also recorded in Logs > Server Action Executions; viewing that log requires the "View action execution log" system access right.

For low-level troubleshooting, enable debug output in the server debug console: the nc tag covers the notification channel framework (debug nc 6), and drivers log under ncd.<driver> tags such as ncd.smtp or ncd.telegram (debug ncd.* 6 enables all driver output).

Troubleshooting Notifications

Email Not Delivered

  • Verify SMTP server address and port

  • Check authentication credentials

  • Test with Send notification…​ in the Notification Channels view

  • Check server logs for SMTP connection errors

  • Verify the sender address is allowed by the SMTP server (SPF, relay restrictions)

SMS Not Delivered

  • Verify GSM modem connection or gateway configuration

  • Check that the phone number format is correct (international format: +1234567890)

  • Verify modem signal strength and SIM card status

  • For gateway drivers (AnySMS, Nexmo, Twilio, etc.): verify API credentials and account balance

Telegram Not Delivered

  • Verify the bot token is correct

  • Ensure the recipient has started a conversation with the bot (bot cannot initiate chats)

  • Check if a proxy is needed for Telegram API access

  • Verify the chat ID is correct (use https://api.telegram.org/bot<TOKEN>/getUpdates to confirm)

Chat Integrations Not Working

  • Verify webhook URLs are correct and active

  • Check that the bot/integration has been added to the channel/room

  • For Microsoft Teams: verify the channel’s Microsoft Teams Workflows (Power Automate) webhook URL — the driver sends messages as Adaptive Cards to Workflows webhooks; legacy Office 365 incoming webhook connectors were retired by Microsoft and are not supported

  • For Slack: verify the webhook URL has not been revoked

Next Steps