Notifications

Seeing events on the Events page is great when you’re looking at GridNMS. Notifications are what reach you when you’re not. This page explains how to create reusable notification destinations and how to turn on notifications for exactly the things you care about — so the right people get paged for the right things, and nobody gets buried in noise.

Notification endpoints are reusable destinations you can point many detections at.

How notifications work

Notifications have two parts that work together:

1. Notification endpoints — where alerts go. A reusable destination like an email address, a Slack channel, a webhook, or a PagerDuty service.
2. A detection’s notification settings — what gets sent. Every alert in GridNMS comes from a detection (a rule that turns a log or telemetry pattern into an event). Turn on Notify on match for a detection and pick its destinations, and you’ll be alerted whenever it fires.

You define endpoints once, then point as many detections at them as you like.

Note

There is no separate “subscriptions” list. Because every alert already corresponds to a detection, notifications live on the detection itself — so there’s always a permanent record of exactly what you were watching for. To be alerted on something new, create a detection for it and turn its notifications on.

Notification endpoints

Open the notification endpoints page to create destinations. GridNMS supports several types:

Email

1. Click Add endpoint and choose Email.
2. Enter the recipient address (a person or a shared team inbox / distribution list).
3. Give it a recognizable name and save.

Good for general awareness and shared mailboxes.

Webhook

1. Choose Webhook.
2. Enter the URL that should receive the event payload.
3. Add any required headers (for example, an authorization token).
4. Save.

Webhooks let you push events into your own systems, ticketing tools, or chat integrations that accept inbound posts.

Slack

1. Choose Slack.
2. Provide the incoming webhook URL for the channel you want to post to.
3. Name it after the channel (e.g. #network-alerts) and save.

Alerts then appear as messages in that channel.

PagerDuty

1. Choose PagerDuty.
2. Enter the integration key for the PagerDuty service you want to alert.
3. Save.

This is the right choice for waking up on-call staff for serious events.

Tip

Name endpoints by destination, not by purpose — e.g. “Slack #network-alerts” or “PagerDuty – Network on-call”. The purpose lives in the detection that points at them, and one endpoint is often reused by several detections.

Turning on notifications for a detection

Open any detection (Event Management → Detections) — or an interface threshold — and in its Notify section:

1. Turn on Notify on match.
2. Choose Notify me to send to your own account, and/or
3. Add one or more endpoints from the dropdown.

That’s it. The next time the detection fires, everyone listed is notified. The same controls appear when you create an interface bandwidth threshold, so a threshold can page you the moment a link saturates.

Because the alert is the detection, the detection also decides when you’re notified — its conditions, severity, and (for problems like a device going down) its auto-clear behaviour all apply. During a site-wide outage, GridNMS rolls many simultaneous device-down events into a single alert instead of paging you once per device.

See everything that notifies: Admin → Notifications

Administrators get a single, system-wide view of every detection that sends a notification, who it alerts, and through which endpoints — under Admin → Notifications. Each row links straight to the detection so you can adjust it. Use this to audit your alerting at a glance: confirm nothing critical is silent, and nothing noisy is paging the whole team.

Delivery and retries

When a detection fires, GridNMS delivers it to each chosen endpoint. If a delivery fails — a Slack webhook times out, a PagerDuty call is briefly rejected — GridNMS automatically retries so a momentary hiccup doesn’t cause a missed alert. Persistent failures (for example, an endpoint URL that no longer exists) are surfaced so you can fix the destination.

Caution

If an endpoint stops working — a rotated Slack webhook, a deleted PagerDuty integration — alerts to it will fail. Review your endpoints periodically and send a test to confirm they still deliver.

Worked example: page on-call when a core switch goes down

Suppose you want your on-call engineer paged whenever a core switch stops responding, while routine warnings just go to a Slack channel.

1. Create the endpoints (once):
   • A PagerDuty endpoint named PagerDuty – Network on-call.
   • A Slack endpoint named Slack #network-alerts.
2. Page on device-down: open the built-in Device down detection, turn on Notify on match, and add the PagerDuty endpoint. (Device down already auto-clears when the device recovers, so the alert resolves itself.)
3. Awareness for the rest: open (or create) the lower-severity detections you want visibility on, turn on Notify on match, and add the Slack endpoint.

Now a core switch going down pages on-call, while lower-severity detections only post to Slack — no one gets woken up for a warning.

Where to go next

• Tune what becomes an event in Events & Alerts.
• Author detections (and interface thresholds) in Detections.
• Understand severity thresholds in severity levels.