Customizing built-in monitors

Customize System and Library monitors and use them as the starting point for a more complex monitor configuration that increases the relevancy of alerts.

To customize a built-in monitor, from Alerts and Diagnostics > Manage alerts in the navigation panel:

Open the action menu of a System or Library monitor and select Configure.
Customize the fields under the General tab.
Adapt the defined NQL Query and conditions tab.
- Including Trigger condition, Filter, ‘group-by’ clause and Scheduling frequency.
Check the configured Notifications via email or webhooks for proactive alert management.

Before using built-in monitors

The following Library monitors require the Collaboration Experience expansion product:

Call quality - Zoom number of poor calls (increase)
Call quality - Teams number of poor calls (increase)

The following System monitors require Nexthink instances fully transitioned to Infinity :

Binary connection establishment time increase
Binary failed connection ratio increase

Updates from Nexthink to Library monitors do not keep your customizations.

To ensure accuracy, the system prevents editing certain fields of built-in monitors, including system and library monitors.

Customizing the General fields of built-in monitors

From the monitor configuration page, check the following fields under the General tab.

Built-in monitors offer the following Trigger methods:
- The Schedule method is used for periodic checks. In the Query and conditions tab, use the Scheduling frequency to set how often the metrics are validated.
- The Events method—restricted to built-in monitors—is used for real-time monitoring to detect issues instantly. In the Query and conditions tab, define the Trigger conditions to set how long the threshold must be breached before an alert is triggered.
Built-in monitors offer the following Types of detection modes:

Metric threshold

Metric threshold triggers an alert when the value of one or more metrics reaches a user-defined threshold.

Metric change

Metric change triggers when the current metric value differs from the rolling 7-day global average beyond the configured threshold.

Metric Seasonal Change

Metric seasonal change triggers an alert when the current metric value falls outside its time-of-day baseline from the last 7 days, based on the configured standard deviation band.

Global detection

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 settings across organizations.

The system uses the monitor Name to send notifications and visualize monitors on the Alerts overview page.
You cannot edit the NQL ID for existing monitors, but can use this ID to query this monitor within Nexthink.

Adapting predefined Query and conditions of built-in monitors

When applicable, built-in monitors have fixed and predefined NQL queries to evaluate specific metrics.

Some built-in monitors do not expose their underlying NQL queries.

From the monitor configuration page, adapt the fields under the Query and conditions tab.

If needed, click the Show in Investigations button to view the query investigation results.

Customize the existing Trigger conditions that activate alerts. Trigger conditions are sensitive to the chosen detection Type for the monitor:

Trigger conditions for Metric threshold

When modifying trigger conditions for built-in monitors with Metric threshold detection, the monitor triggers alerts based on relational operators—greater than or equal to, less than or equal to—against the value you set.

Trigger conditions for Metric change

When modifying trigger conditions for built-in monitors with Metric change detection:

The first trigger condition represents the deviation rule—higher or lower—that proportionally compares the current metric to the baseline (7-day global average).

Additional trigger conditions define when the alert activates, based on relational operators—greater than or equal to, less than or equal to—against the defined threshold.

In this example below, the monitor triggers an alert when the CPU Usage value doubles the metric average over the last 7 days.

These trigger conditions apply to both Schedule and Events-trigger monitors.

Trigger conditions for Metric seasonal change

When modifying trigger conditions for built-in monitors with Metric seasonal change detection:

The first trigger condition sets the sensitivity band or range computed the from time-of-day baseline from the last 7 days. The monitor triggers an alert when the current metric value falls outside the selected standard deviation range for that time slot:
- slightly = ± one standard deviation (±1σ)
- moderately = ± two times the standard deviation (±2σ)
- highly = ± three times the standard deviation (±3σ)

Additional trigger conditions define when the alert activates, based on relational operators—greater than or equal to, less than or equal to—against the defined threshold.

In this example below, the monitor triggers an alert when the Percentage of failed connections is outside the band of plus or minus two standard deviations (±2σ) from the baseline.

In the case of built-in monitors with an Events trigger, the system provides an additional time-based trigger condition:

Trigger conditions for Global detection

When customizing built-in monitors with Global detection, the monitor triggers alerts based on relational operators—greater than or equal to, less than or equal to—against the value you set, to flag when a particular binary version or binary configuration performs worse than other versions or configurations across organizations.

Global detection method is only available for built-in monitors with an Events trigger.

Add Filters using where conditions—up to 20 property values—to include or exclude certain applications or devices from being monitored
- Filters are only available for built-in monitors that evaluate objects: users, devices, applications, and binaries.
Add 'group-by' clauses for built-in monitors tracking device performance and call quality issues per organizational hierarchy breakdown, including custom levels and location breakdowns.
- To use breakdown by location, as an optional 'group-by' in device performance monitors, you should enable the geolocation in the Product configuration.
Review the fixed Scheduling frequency of the built-in monitor to determine how often the system evaluates the trigger condition. Refer to the Getting started with Alerts documentation to learn more about scheduling data points for alert triggering.

An alert Scheduling frequency, for example of 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.

Choose an alert auto-recovery option. In many alert scenarios, the built-in monitor does not need to extend the recovery period by 72 hours, as the Trigger condition is normalized:
- In these cases, recover alerts immediately after the monitor's first evaluation returns no data due to inactivity.
- On the contrary, you may decide to wait 72 hours to, for example, account for a weekend break and keep the alert open during this inactivity period—instead of closing and opening a new alert.