Creating custom monitors

To create a custom monitor for alerts, from Alerts and Diagnostics > Manage alerts in the navigation panel:

1. Click on the New monitor button in the top-right corner of the page to open the monitor configuration.

2. Fill in the fields under the General tab.

3. Define the NQL Query and conditions tab.

   • Including Trigger condition and Scheduling frequency.

4. Configure Notifications via email or webhooks for proactive alert management.

Filling in the General tab

From the New monitor configuration page, fill in the following fields under the General tab:

• Type: Custom monitors offer The Metric threshold detection mode to compare the value of the NQL query-defined metric to the threshold you define. For example, a monitor triggers an alert when 20% of devices running a binary experience a crash.

• Name: Provide a meaningful name for the monitor. The system uses this name to send notifications and visualize monitors on the Alerts overview page.

• NQL ID: The system automatically generates a unique identifier from the monitor Name.

  • You can only modify the NQL ID during the monitor creation process using the following characters a-z, 0-9, _. Meaning, you cannot edit this field once you have created the monitor.

  • Use the NQL ID to query this monitor using NQL.

  • You cannot create a monitor with an NQL ID that was used by a deleted monitor until there are no events in the system still associated with the deleted monitor (30 days max).

• Priority: Set the priority level. The default level is medium.

• Tags: Create custom tags for monitors. This allows you to filter alerts using tags in the Overview dashboard and in the Webhooks integration. Currently, there is a maximum of ten tags per monitor.

Defining NQL Query and conditions

From the New monitor configuration page, under the Query and conditions tab:

1. Use an NQL query input field to define the metrics to monitor. NQL facilitates the selection of one or multiple metrics, helps specify the scope with the where clause and defines the right granularity for the alert context using time aggregation and the by keyword for grouping.

2. If needed, use the Show in Investigations button to view the results of your NQL query in the Investigations module.

NQL rules and limitations for monitor queries

The NQL query must follow several rules to support monitors:

1. The NQL query for monitors must include a computed or aggregated metric, which means every query requires a compute or summarize clause to be compatible with a monitor.

devices
| with device_performance.system_crashes during past 7d 
| compute 
  total_number_of_system_crashes = number_of_system_crashes.sum()

execution.crashes during past 24h
| summarize total_number_of_crashes = count()

1. Optionally, include more than one computed or aggregated metric in your query to set multiple conditions for the alert to be triggered.

execution.crashes during past 24h
| summarize 
  total_number_of_crashes = count(), 
  devices_with_crashes = device.count()

1. Use at least one metric to set a threshold for monitoring conditions. Create an additional metric if your original query does not include one.

Not compatible with monitors:

devices
| with antiviruses
| where is_up_to_date == no

Compatible with monitors:

devices
| with antiviruses
| where is_up_to_date == no
| compute device_count = count()

1. Do not add conditions to evaluated metrics at the NQL level. Instead, use the Trigger condition section to define the condition.

Incorrect monitor NQL query:

execution.crashes during past 24h
| summarize total_number_of_crashes = count()
| where total_number_of_crashes >= 10

Correct monitor NQL query with conditions:

execution.crashes during past 24h
| summarize total_number_of_crashes = count()

1. Use the where clause to narrow the scope of your monitor to specific locations, applications and other categories.

execution.crashes during past 24h
| where binary.name == "excel.exe"
| summarize total_number_of_crashes = count()

1. Use summarize... by to define the right granularity for the alert context. In the following example, a single alert will be triggered per binary name.

execution.crashes during past 24h
| summarize total_number_of_crashes = count() by binary.name

Refer to the Detecting issues impacting multiple devices and Detecting issues impacting a single device or user documentation to learn more about defining the NQL query.

Defining Trigger conditions

From the New monitor configuration page, under the Query and conditions tab, define the Trigger condition that activates the alert.

Use each metric computed in the NQL query to narrow down the condition.

Defining Scheduling frequency

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.

The scheduling frequency determines how often the system evaluates the trigger condition. The possible timeframes are 15 min, 1 hour, 3 hours, 6 hours, 12 hours, 24 hours, 48 hours and 7 days. However, the availability of these timeframes depends of the during past clause and the events queried with the monitor's NQL query.

See the following examples to understand how setting monitor query determines the available scheduling frequency:

Monitored events with during past	Minimum frequency	Maximum frequency
device_performance.boots during past 24h	15 min	7 days
device_performance.boots during past 7d	24 h	7 days
session.events during past 1h	15 min	7 days
session.events during past 24h	12h	7 days
execution.events during past 1h	15 min	7 days
execution.events during past 24h	12h	7 days
execution.events during past 7d	7 days	7 days

Choosing Alert auto-recovery options

In many alert scenarios, the monitor does not need to extend the recovery period by 72 hours, as the Trigger condition is normalized.

In these cases, use the Auto recovery options for Advanced monitor configurations under the Query and conditions tab to 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.

---

Creating custom monitors for VDI—limitations

While built-in monitors for virtual desktops (VDI) provide out-of-the-box functionality with limited customization, you can create custom VDI monitors for specific organizational needs.

Consider the following when creating custom VDI monitors:

• Set the Trigger to the only available option for custom VDI monitros: Schedule trigger, with a minimum granularity of 15 minutes.

• Use VDI-related NQL tables and fields in the Query and conditions. For example, you can create a monitor to detect sessions with latency above 50ms:

  session.vdi_events
  | summarize average_latency = avg(session.network_latency)
  | where average_latency > 50

---

Importing a custom monitor

One way to create monitors is by importing them from a previously exported configuration file.

The system does not allow the import of a monitor with the same NQL ID as a deleted monitor if there are events in the system still associated with that deleted monitor. Alert events are kept in the platform for 30 days maximum.

If the NQL ID is already used in deleted monitor with existing alerts message appears during the import of the monitor, please modify the export file to create a new NQL ID.

---

RELATED TOPICS

• Detecting issues impacting multiple devices

• Detecting issues impacting a single device or user

• Nexthink Library

• Product configuration