---
id: create-monitor
title: Create a New Monitor
description: Create Sumo Logic monitors with ML-powered anomaly detection, customizable trigger conditions, playbook automation, and alerting for logs and metrics.
slug: /help/docs/alerts/monitors/create-monitor/
canonical: https://www.sumologic.com/help/docs/alerts/monitors/create-monitor/
---
import useBaseUrl from '@docusaurus/useBaseUrl';
import Iframe from 'react-iframe';
This guide will walk you through the steps of creating a monitor in Sumo Logic, from setting up trigger conditions to configuring advanced settings, notifications, and playbooks.
Our alerts use machine learning to analyze historical data, establish baselines, detect significant deviations, and filter out irrelevant alerts to reduce alert fatigue and help teams focus on critical issues. These capabilities apply to both logs and metrics, providing a comprehensive monitoring solution. With seasonality detection and customizable anomaly clustering, false positives are minimized, enabling faster issue resolution.
Integrated playbooks automate incident response by gathering diagnostics, notifying teams, triggering recovery actions, and streamlining workflows to improve response times. You can link playbooks to monitors to automate tasks such as restarting services or scaling infrastructure, ensuring swift and efficient anomaly resolution.
import TerraformLink from '../../reuse/terraform-link.md';
:::tip
You can use Terraform to manage monitors with the [`sumologic_monitor`](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs/resources/monitor) and [`sumologic_monitor_folder`](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs/resources/monitor_folder) resources.
:::
## Open the New Monitor window
There are several ways to create a new monitor, depending on where you are in Sumo Logic.
### From Monitors
1. [**New UI**](/docs/get-started/sumo-logic-ui). In the main Sumo Logic menu, select **Monitoring > Monitors**. You can also click the **Go To...** menu at the top of the screen and select **Monitors**. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the main Sumo Logic menu, select **Manage Data > Monitoring > Monitors**.
1. Click **Add** > **New Monitor**, and the **New Monitor** dialog box will appear.
### From Metrics Search
Creating a monitor based on the threshold values defined in the Metrics page can save time and effort. By using the pre-filled monitor editor, you can quickly create a monitor with the same threshold values as defined in the Metrics page. This will ensure that the monitor is using the same criteria as the Metrics page, providing consistency in monitoring.
To create a monitor from the [Metrics Search](/docs/metrics/metrics-queries/metrics-explorer/), follow the steps below:
1. Open the **Metrics Search**:
* [**New UI**](/docs/get-started/sumo-logic-ui). Click the **Go To...** menu at the top of the screen and select **Metrics Search**.
* [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). From Sumo Logic home, click **Metrics**.
1. On the **Metrics Search** page:
1. Enter a metrics query.
1. In the **Thresholds** section, define the critical and warning thresholds for your metrics query.
1. Click the three-dot kebab icon button at the end of the query field and select **Create a Monitor**.
1. The **New Monitor** will open with prefilled data based on the threshold values you set in the previous steps.
1. In the **Trigger Type** section, enable the checkbox that corresponds to the threshold value that you want to use (Critical and/or Warning).
* The threshold values will be the same as defined in the Metrics page for both Critical and Warning thresholds.
* Set all other parameters to default, including the window (15 minutes) and the **at all times** box.
* Ensure that the Recover value is set to the default, which is the opposite of the Alert value. The Edit Recovery button should be off.
1. Once all values have been set, click **Save** to create the monitor.
1. The same threshold will also be applied to the histogram chart.
:::note
The same threshold translating functionality supports [opening the Alerts Response Page in the Metrics Search](/docs/alerts/monitors/alert-response/#translating-thresholds) and [opening a monitor in the Metrics Search](/docs/alerts/monitors/settings/#view-in-metrics-search).
:::
:::tip
When you create a monitor and open the metrics search query in the Metrics Search, the signal gets a new value for the [`quantize`](/docs/metrics/metrics-operators/quantize/) operator based on the time range of the query. The default value for the `quantize` operator is `1m`. Because opening the query in Metrics Search may not match because of quantization differences, you may need to adjust the query to return the results you expect, especially when creating a monitor that uses the [anomaly detection method](#detection-method).
:::
## Step 1. Set trigger conditions
The first step when creating a new monitor is setting the **Trigger Conditions**, a thresholds value that must met to trigger an alert. Applicable values include Critical, Warning, and Missing Data. These values are set when you create a monitor and can be based on a variety of metrics such as CPU usage, network latency, application response time.
### Monitor Type
Select a **Monitor Type**, which will create alerts based on [Logs](/docs/search/), [Metrics](/docs/metrics/metrics-queries/), or an [SLO](/docs/observability/reliability-management-slo/).
### Detection Method
Next, select a **Detection Method** (not applicable to SLO monitors).
#### Static
Set specific threshold conditions for well-defined KPIs with constant thresholds (for example, infrastructure metrics like CPU utilization and memory).
#### Anomaly
Leverage machine learning to identify unusual behavior and suspicious patterns by establishing baselines for normal activity. This alerting system uses historical data to minimize false positives and alerts you to deviations.
* **Model-driven detection**. Machine learning models create accurate baselines, eliminating guesswork and noise.
* **AutoML**. The system self-tunes with seasonality detection, minimizing user intervention and adjusting for recurring patterns to reduce false positives.
* **User-defined sensitivity**. Users set alert sensitivity and thresholds, providing context to filter out noise.
* **One-click playbook assignment**. Monitors automatically link to [Sumo Logic Automation Service playbooks](#automated-playbooks), expediting incident response.
* **Auto-diagnosis and recovery**. The Automation Service handles diagnosis and resolution, closing the loop from alert to recovery.
* **Customizable detection**. Use advanced rules like "Cluster anomalies" to detect multiple data points exceeding thresholds within a set timeframe.
:::training Micro Lesson
Watch this micro lesson to learn about anomaly monitors.
:::
**Use Outlier**
If you want to trigger alerts on outlier direction rather than anomaly detection, select **Anomaly** and enable **Use Outlier**. This detects unusual changes or spikes in a time series of a key indicator. Use this detection method when you are alerting on KPIs that don't have well-defined constant thresholds for what's good and bad. You want the monitor to automatically detect and alert on unusual changes or spikes on the alerting query. For example, application KPIs like page request, throughput, and latency.
#### Anomaly or Outlier Direction
If you choose an anomaly or outlier detection method, you'll need to select the **Anomaly Direction** or **Outlier Direction** you want to track (not applicable to static detection method).
* **Up**. Get alerted if there is an abnormal *increase* in the tracked key indicator.
* **Down**. Get alerted if there is an abnormal *decrease* in the tracked key indicator.
* **Both**. Get alerted if there is *any* abnormality in the data whether an increase or a decrease.
### Query
:::tip
For guidance on optimizing scan costs when using Flex Pricing, refer to the [FAQ on optimizing scan costs for monitors](/docs/alerts/monitors/monitor-faq/#how-can-i-optimize-scan-costs-for-monitors-when-using-flex-pricing).
:::
In this step, you'll need to provide a logs or metrics query. This is not applicable to SLO monitors.
#### Logs
Logs monitors can have one query up to 15,000 characters long.
#### Metrics
Metrics monitors can have up to 6 queries. If you're providing multiple metrics queries, use the letter labels to reference a query row. The monitor will automatically detect the query that triggers your alert, and will mark that row with a notification bell icon. See [Join metrics queries](/docs/metrics/metrics-queries/metrics-explorer/#join-metric-queries) for details.
### Trigger Type (Logs)
You can set a logs monitor trigger to alert based on the following:
* A **returned row count** (default), which is the number of rows returned from the log search.
* A numeric field returned from the search. You can pick any numeric field from your query, and alert on the value of that field. The field is `_count` in the above screenshot. To convert a string to a number use the [`num` operator](/docs/search/search-query-language/search-operators/num). For example, if you have a field named **duration**, you would use the `num` operator as follows to convert it to a number value.
```sh
| num(duration)
```
Triggers are evaluated by balancing the requirement of timely alert notifications while ensuring that monitor data is indeed available to evaluate trigger conditions.
* For [static logs monitors](#static-detection-method), you can control trigger monitor evaluation frequency using the options below. If `Alert when result is than <_> within . Evaluate trigger every .`:
| When detection window (X) is | Evaluate trigger every (Y) |
|:-----|:----------------------|
| 5m | 1m, 2m |
| 10m | 1m, 2m, 5m |
| 15m | 1m, 2m, 5m, 10m |
| 30m | 2m, 5m, 10m, 20m |
| 1h | 2m, 5m, 10m, 20m |
| 3h | 10m, 20m, 40m, 1h |
| 6h | 10m, 20m, 40m, 1h |
| 12h | 20m, 40m, 1h |
| 24h | 20m, 40m, 1h |
* For [anomaly logs monitors](#anomaly-detection-method), triggers are evaluated every `timeslice` as specified in the monitor query. For example, the below query is evaluated every 2 minutes.
```
_sourceCategory=Labs/Apache/Access
| timeslice 2m
| parse "HTTP/1.1\" * " as status_code
| if (status_code = "200", 1, 0) as successes
| if (status_code = "404", 1, 0) as fails
| sum(successes) as success_cnt, sum(fails) as fail_cnt by _timeslice
| (fail_cnt/(success_cnt+fail_cnt)) * 100 as failure_rate_pct
```
* For [outlier logs monitors](#outlier-detection-method), triggers are evaluated every 5 minutes.
When configuring monitor trigger conditions, you can set a resolution window to resolve alerts quickly once the underlying issue is fixed. The resolution window specifies how long a monitor will wait before resolving an alert after the issue is corrected.
For example, if your monitor evaluates the last 1 hour, you can set a resolution window of 15 minutes. Once the resolution window is continuously satisfied for 15 minutes, the alert will resolve automatically.
#### Static detection method
**Example: Logs - Static - Critical and Warning**
`Alert when result is within
})
#### Static detection method
**Example: Logs - Static - Critical and Warning**
})
`Alert when result is })
1. On the **Metrics Search** page:
1. Enter a metrics query.})
1. In the **Thresholds** section, define the critical and warning thresholds for your metrics query.})
1. Click the three-dot kebab icon button at the end of the query field and select **Create a Monitor**.})
1. The **New Monitor** will open with prefilled data based on the threshold values you set in the previous steps.})
1. In the **Trigger Type** section, enable the checkbox that corresponds to the threshold value that you want to use (Critical and/or Warning).
* The threshold values will be the same as defined in the Metrics page for both Critical and Warning thresholds.
* Set all other parameters to default, including the window (15 minutes) and the **at all times** box.
* Ensure that the Recover value is set to the default, which is the opposite of the Alert value. The Edit Recovery button should be off.
1. Once all values have been set, click **Save** to create the monitor.
1. The same threshold will also be applied to the histogram chart.
:::note
The same threshold translating functionality supports [opening the Alerts Response Page in the Metrics Search](/docs/alerts/monitors/alert-response/#translating-thresholds) and [opening a monitor in the Metrics Search](/docs/alerts/monitors/settings/#view-in-metrics-search).
:::
:::tip
When you create a monitor and open the metrics search query in the Metrics Search, the signal gets a new value for the [`quantize`](/docs/metrics/metrics-operators/quantize/) operator based on the time range of the query. The default value for the `quantize` operator is `1m`. Because opening the query in Metrics Search may not match because of quantization differences, you may need to adjust the query to return the results you expect, especially when creating a monitor that uses the [anomaly detection method](#detection-method).})
:::
## Step 1. Set trigger conditions
The first step when creating a new monitor is setting the **Trigger Conditions**, a thresholds value that must met to trigger an alert. Applicable values include Critical, Warning, and Missing Data. These values are set when you create a monitor and can be based on a variety of metrics such as CPU usage, network latency, application response time.
### Monitor Type
Select a **Monitor Type**, which will create alerts based on [Logs](/docs/search/), [Metrics](/docs/metrics/metrics-queries/), or an [SLO](/docs/observability/reliability-management-slo/).})
### Detection Method
Next, select a **Detection Method** (not applicable to SLO monitors).
})
#### Static
Set specific threshold conditions for well-defined KPIs with constant thresholds (for example, infrastructure metrics like CPU utilization and memory).
#### Anomaly
Leverage machine learning to identify unusual behavior and suspicious patterns by establishing baselines for normal activity. This alerting system uses historical data to minimize false positives and alerts you to deviations.
* **Model-driven detection**. Machine learning models create accurate baselines, eliminating guesswork and noise.
* **AutoML**. The system self-tunes with seasonality detection, minimizing user intervention and adjusting for recurring patterns to reduce false positives.
* **User-defined sensitivity**. Users set alert sensitivity and thresholds, providing context to filter out noise.
* **One-click playbook assignment**. Monitors automatically link to [Sumo Logic Automation Service playbooks](#automated-playbooks), expediting incident response.
* **Auto-diagnosis and recovery**. The Automation Service handles diagnosis and resolution, closing the loop from alert to recovery.
* **Customizable detection**. Use advanced rules like "Cluster anomalies" to detect multiple data points exceeding thresholds within a set timeframe.
:::training Micro Lesson
Watch this micro lesson to learn about anomaly monitors.
:::
**Use Outlier**
If you want to trigger alerts on outlier direction rather than anomaly detection, select **Anomaly** and enable **Use Outlier**. This detects unusual changes or spikes in a time series of a key indicator. Use this detection method when you are alerting on KPIs that don't have well-defined constant thresholds for what's good and bad. You want the monitor to automatically detect and alert on unusual changes or spikes on the alerting query. For example, application KPIs like page request, throughput, and latency. })
#### Anomaly or Outlier Direction
If you choose an anomaly or outlier detection method, you'll need to select the **Anomaly Direction** or **Outlier Direction** you want to track (not applicable to static detection method).
* **Up**. Get alerted if there is an abnormal *increase* in the tracked key indicator.
* **Down**. Get alerted if there is an abnormal *decrease* in the tracked key indicator.
* **Both**. Get alerted if there is *any* abnormality in the data whether an increase or a decrease.
### Query
:::tip
For guidance on optimizing scan costs when using Flex Pricing, refer to the [FAQ on optimizing scan costs for monitors](/docs/alerts/monitors/monitor-faq/#how-can-i-optimize-scan-costs-for-monitors-when-using-flex-pricing).
:::
In this step, you'll need to provide a logs or metrics query. This is not applicable to SLO monitors.
#### Logs
Logs monitors can have one query up to 15,000 characters long.
#### Metrics
Metrics monitors can have up to 6 queries. If you're providing multiple metrics queries, use the letter labels to reference a query row. The monitor will automatically detect the query that triggers your alert, and will mark that row with a notification bell icon. See [Join metrics queries](/docs/metrics/metrics-queries/metrics-explorer/#join-metric-queries) for details.})
### Trigger Type (Logs)
You can set a logs monitor trigger to alert based on the following:
* A **returned row count** (default), which is the number of rows returned from the log search.})
* A numeric field returned from the search. You can pick any numeric field from your query, and alert on the value of that field. The field is `_count` in the above screenshot. To convert a string to a number use the [`num` operator](/docs/search/search-query-language/search-operators/num). For example, if you have a field named **duration**, you would use the `num` operator as follows to convert it to a number value.
```sh
| num(duration)
```
Triggers are evaluated by balancing the requirement of timely alert notifications while ensuring that monitor data is indeed available to evaluate trigger conditions.
* For [static logs monitors](#static-detection-method), you can control trigger monitor evaluation frequency using the options below. If `Alert when result is