Alerts FAQ
About Nexthink Alerts' detection and logic:
What types of alert detection modes are available?
Alerts detect critical issues based on the following detection modes:
Metric threshold triggers an alert when the value of one or more metrics reaches a user-defined threshold.
Metric change triggers an alert when the current metric value differs from the rolling 7-day global average beyond the configured threshold.
Metric seasonal change triggers an alert when the current metric value falls outside its time-of-day baseline from the last seven days, based on the configured standard deviation band.
Global detection—only available for built-in monitors—triggers an alert when a specified number of devices use a particular binary version or binary configuration that performs worse than other versions or configurations across organizations.
Explore the Alerts FAQ to learn how the system computes the baseline for Metric change or Metric seasonal change detection modes.
You can configure up to 5 custom monitors in total using either Metric change or Metric seasonal change.
You can create up to 50 monitors.
What are the methods for triggering alerts?
Nexthink monitors trigger alerts using one of the following methods:
The Schedule trigger method—available for custom and built-in monitors—is used for periodic checks. The monitor evaluates the metric(s) in regular intervals defined by the configured schedule frequency.
The Events trigger method—restricted to built-in monitors—is used for real-time monitoring and instant issue detection. Depending on the configured monitor Query and conditions, the monitor evaluates how long a threshold must be breached to trigger an alert.
Setting an alert scheduling frequency, for example to 7 days, means the monitor evaluates the alert every 7 days, starting on the 1st of each month.
This may cause the system to trigger alerts sooner than expected, such as one alert on the 28th of a specific month, but triggered again on the 1st of the month after.
How does the system handle excessively triggered alerts?
Nexthink limits the total number of objects that can trigger the same alert to 500, keeping individual alerts relevant.
When a single monitor triggers 500 or more alerts concurrently, Nexthink activates an alert-grouping mechanism to prevent system flooding. This means the monitor stops generating additional alerts until the situation is resolved—therefore, grouped alerts act as one when handled.
This alert grouping behavior is captured in the NQL data model through the is_grouped field..
How does the system determine when to close alerts?
The system closes the alert when a monitored metric no longer breaches defined conditions.
If the monitor tracks metric threshold, the system closes the alert when a monitored metric no longer breaches the threshold.
If the monitor tracks metric change, the system closes the alert when that metric value drops down to the baseline.
If the monitor query does not return any data during evaluation, the alert automatically closes according to the following rules:
For alerts that track aggregated metrics across multiple devices, the alert closes if there are three consecutive days of no data returned.
For alerts triggered for a single device or user, the alert closes if the monitor query continuously returns no data during the period specified in the
during pastparameter of the query.
When does the system notify about triggered or closed alerts?
The system sends a notification—if configured—when specific alerts are triggered or closed.
If the alert was triggered in a previous evaluation and already has an Open status, the system does not send a notification if the metric still meets the detection criteria in the current evaluation.
Refer to the Responding to Alerts documentation to learn how to react and respond to alert notifications.
How does the system compute the Baseline for the detection methods: Metric change and Metric seasonal change
Baseline computation depends on the alert detection mode:
For Metric change: The baseline is the rolling 7-day global average (mean) of all data points returned by the monitor’s query. The current value is evaluated against this average using your configured threshold.
For Metric seasonal change: The baseline is time-of-day aware, meaning that for each time slot (for example, Monday 10:00–11:00) Nexthink computes the mean from the same slot across the last 7 days and evaluates divergences using standard-deviation bands:
slightly is one standard deviation (±1σ)—values are within ±1σ.
moderately is two times the standard deviation (±2σ)—values are within ±2σ.
highly is three times the standard deviation (±3σ)—values are within ±3σ.
Visualize the computed baseline in the Diagnostics dashboard timeline.
Scheduling frequency for baseline data points
The monitor Scheduling frequency defines how many data points feed the baseline, coherent with the detection type:
For Metric change, the system uses a few data points (about 20 evaluations) to compute the baseline, meaning the monitor could trigger an alert within 7 days after activation.
For Metric seasonal change, the system waits 7 days before it can trigger an alert. This ensures that at least 7 data points—one for each day, for the same timeslot—are available for standard deviation estimations.
Subsequently, the scheduling frequencies change according to the detection type:
For Metric change, the scheduling frequency ranges from 15 minutes to several days.
For Metric seasonal change, the maximum scheduling frequency is 24 hours, as more than 1-day frequency does not contribute to computing the mean for the same slot across the last 7 days.
The 12 hours schedules yield two daily slots; each slot still uses 7 historical points (one per day) for its baseline.
About Nexthink Alerts' scope and practical uses:
How many monitors can I set up?
You can configure up to 5 custom monitors in total using either Metric change or Metric seasonal change detection modes.
You can create up to 50 monitors.
When to use alerts and when to use data exporters?
Use alerts to detect issues requiring immediate assistance or action. For other reports or events that do not need swift action, such as Report all devices with low disk space, use a data exporter.
Also, use data exporters to report on a large number of objects that meet specific condition criteria expressed with an NQL query, or if you expect a single monitor to trigger more than 500 alerts at the same time.
Additionally, use the data export scheduling option to export data regularly.
How can I prevent triggering alerts due to metric spikes when only a few users are affected?
A recommended way to ensure alerts are not triggered when very few devices are active, for example, during weekends, is to use multiple thresholds. Create a monitor and define your main evaluated metric. Additionally, compute more metrics, such as the number of active users and devices with issues, and use them as additional thresholds.
How can I investigate and query devices associated with an existing alert?
The NQL data model stores devices associated with an existing alert in different NQL tables based on the specific use case:
Single-device alerts where one alert is tied to one device.
alert.alerts stores the device name.
Multiple-device alerts indicating widespread issues—one alert is potentially linked to multiple devices.
alert.impacts stores all impacted devices.
Refer to the Getting started with Alerts documentation to learn more about configuring alert monitors that detect issues impacting single or multiple devices.
About Nexthink Alerts' integrations with third-party tools:
How can I integrate Alerts with various tools, including ITSM systems like ServiceNow?
Use Webhooks to integrate Nexthink with other Software as a Service (SaaS) applications. Refer to the Webhooks documentation for more information.
What security measures are in place for Nexthink integrations via Webhooks?
As of today, webhooks support authentication using:
OAuth2 – Client Credentials
OAuth2 – Authorization Code
Basic
Bearer Token
No Auth (None)
We rely on the third-party services receiving notifications to accept one of these security methods.
How do I notify only the respective application team about alerts triggered for their specific application?
Use Webhooks to distribute notifications to different destinations based on the alert content such as payload, priority, tags or monitor name.
For example, to configure notifications displayed in specific MS Teams channels whenever an alert is triggered for the Salesforce application, follow these steps:
Create a webhook outbound connector to the MS Teams channel. Refer to the Webhook documentation for more details.
Select monitors that should send notifications to the respective MS Teams channel upon alert triggering. Nexthink recommends using monitor Tags to identify more than one monitor. In this example, use the web-applications tag for all monitors that trigger application alerts.
Ensure each alert contains the application name in the alert payload, in this case, Salesforce.
Write a webhook NQL query that selects only those alerts that should send notifications to the given channel. See the example below.
alert.alerts | where monitor.tags contains "web-applications" | where alert.context contains "*Salesforce*" | list alert.monitor.name, alert.status, monitor.tags, alert.context, trigger_time, recovery_time, alert.monitor.thresholds, monitor.priority, alert.trigger_values, alert.trigger_reference_value, alert.recovery_valuesCreate a webhook payload that the system will send as a notification message. Use dynamic variables to send information about the details of the triggered alert.
Can I send a notification about the closed alert to ServiceNow to update the ticket?
Yes. The alerting system sends two messages to webhooks for each alert: one message when the alert is triggered and another message when the alert is closed. Send alert.status in the notification payload to the ITSM system to react to both messages. The alert UID is the unique key of the alert, which is the same for both messages. When querying alert events using NQL, you will only retrieve one alert event per unique ID. When the alert is closed, that event is updated with the new status.
Can I send additional device fields, such as the last logged user or Entity, with an alert sent to ServiceNow via webhook?
Yes. Create a monitor that detects issues impacting a single device and contains the device in the payload to send notifications and open ITSM tickets for a single device. Do not include additional device properties in the alert payload. Instead, use these device properties in the notification message when creating a webhook. Example webhook query:
alert.alerts
| where monitor.tags contains "device"
| list alert.monitor.name, alert.status, alert.uid,
trigger_time, recovery_time, device.Entity,
device.hardware.type, device.login.last_login_user_nameLast updated
Was this helpful?