Getting started with Alerts

Alerts are critical enablers in the proactive journey of IT support teams. They allow teams to detect issues and help them prioritize their efforts to improve the digital employee experience (DEX).

How can alerts help you detect and diagnose issues?

Nexthink Alerts notifies you about issues that require swift action by filtering the noise so you can identify situations that require actual user intervention.

Use alerts to identify situations where something has unexpectedly changed or occurred.

Detecting global issues impacting your environment

Detect issues Nexthink identifies based on the cross-organization statistics that impact your environment with Alerts cloud insights:

Learn about binary reliability and performance, and detect anomalies such as abnormal CPU usage.
Quickly identify impacted binary versions and find the recommended version.

For example, the system triggers an alert when more than 50 devices use a certain binary configuration—binary version on a given operating system version—that consumes more memory than other configurations across many organizations.

Refer to the Alerts overview and Understanding cloud insights documentation to learn how to monitor and use alerts for diagnostic purposes.

Detecting issues impacting single or multiple devices/users

Proactively monitor issues according to your needs, whether at the device level, focusing on a single user or device, or addressing widespread incidents affecting multiple devices or sudden performance degradation.

Detect the number of devices or users with issues

Detect whether a certain number of devices or users experienced an issue.

For example, the system triggers an alert when more than 20 devices had a boot time of over 60 seconds, within the past 24 hours.

Detect frequent issues across devices

Monitor the values of any metric across multiple devices to detect whether an aggregated metric value has breached the defined threshold, or shifts by a specific percentage.

For example, the system triggers an alert when the number of crashes of any binary increases by 100% in relation to a predefined norm, like the average of a metric value over the last 7 days.

Detect a specific device or user with issues

Monitor issues on a single device or for a specific user to subsequently trigger alerts if applicable. Send separate notifications for each device or user.

For example, the system triggers an alert for each device that had at least 2 system crashes within the last 24 hours and creates a ticket in the ITSM software on behalf of the user.

Alerts also support detecting issues impacting virtual desktop infrastructures (VDI).

Refer to the Detecting issues impacting multiple devices and Detecting issues impacting a single device or user documentation for more information.

In addition, review the Alerts FAQ to learn how to investigate devices associated with an existing alert, using NQL queries.

What is the difference between an alert and a monitor?

Refer to the Managing Alerts documentation to learn more about monitors, monitor types and monitor creation.

An alert is a special type of event triggered when specific conditions are met for the performance metrics of different features of your IT infrastructure, such as system crashes, load times, or failed connections.

The system sends alerts as emails or webhook notifications to inform your IT teams about issues within your organization. Triggered alerts are visualized in the timeline on the Alerts overview page.

A monitor is a component of the Alerts and Diagnostics module that you configure to evaluate metrics against defined conditions and trigger alerts to identify specific issues. Monitors can be custom-created or built-in (system monitors or installed from Nexthink Library).

With monitors, the Nexthink platform offers anomaly detection capabilities for IT environments and allows you to notify users accordingly.

Monitors for virtual desktop infrastructure—VDI

Using built-in Nexthink Library VDI monitors for Alerts requires Nexthink VDI experience.

Nexthink Library offers built-in VDI-specific monitors to track real-time performance metrics and user experience in virtual desktop infrastructures.

Find below some of the use cases that built-in library VDI monitors allow you to address:

Detect network congestion causing latency spikes in specific office locations.
Identify CPU bottlenecks affecting virtual desktops.
Prevent overloading of a desktop pool to maintain optimal user experience.
Identify network instability affecting session continuity.

Built-in library monitors are partially customizable by allowing you to add trigger conditions or adjust thresholds, depending on the case.

Built-in library VDI monitors use Event or Shedule triggers and different alert detection modes.

For custom monitors using VDI fields to configure Query and Conditions, the system restricts the monitor trigger to Schedule, with a minimum granularity of 15 minutes.

When to use alerts and when to use data exporters?

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.
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.

Additionally, use the data export scheduling option to export data regularly.

What types of alert detection modes are available?

Metric change, Metric Seasonal Change and Global detection are only available for built-in monitors (system monitors or installed from Nexthink Library).

Refer to the Customizing built-in monitors documentation for more information about detection types

Nexthink 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 reference baseline, which is the average of the metric values retrieved over the past 7 days.
Metric Seasonal Change triggers an alert when the current metric value deviates beyond its expected average range—calculated using standard deviations from values collected over the past 7 days.
Global detection 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 using Nexthink. Adjust the threshold for this alert within your organization.

How does the system trigger and close an alert?

Each NQL query-based monitor evaluates the metric(s) in regular intervals, according to the schedule defined in the specific monitor. During each evaluation it determines whether to trigger a new alert, close the open alert or keep the alert status open.

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.

Triggering alerts

The system triggers the alert when the condition criteria defined in the monitor are breached during scheduled evaluation. Once the system triggers the alert, it remains in an Open state until the metric values stabilize and the alert is closed during one of the subsequent evaluations.

Handling 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.

Closing 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 past parameter of the query.

Sending alert notifications

If you have configured notifications for your alert, the system sends them only when the alert is triggered and when the alert is 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.

Granting permissions for Alerts

Refer to the Roles documentation for a detailed description of Permissions, View domain options and Data privacy granularity settings.

To enable proper permissions for Alerts as an administrator:

Select Administration > Roles from the main navigation panel.
Create a New Role or edit an existing role by hovering over it.
In the Permissions section, scroll down to the Alerts section to enable appropriate permissions for the role.

View domain impact on Alerts permissions

The table below shows what users with full and limited view domain access can do, assuming the necessary permissions are enabled.

Permission

Full access

Limited access

Manage all alerts

View all alert dashboards