---
title: Create a Scheduled Rule
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > Cloud SIEM > Detect and Monitor > Custom Detection
  Rules > Create a Custom Rule > Create a Scheduled Rule
---

# Create a Scheduled Rule

## Overview{% #overview %}

Scheduled detection rules run at predefined intervals to analyze indexed log data and detect security threats. These rules can identify patterns, anomalies, or specific conditions within a defined time frame, and trigger alerts or reports if the criteria are met.

Scheduled rules complement real-time monitoring by ensuring periodic, in-depth analysis of logs using [calculated fields](https://docs.datadoghq.com/logs/explorer/calculated_fields/).

## Create a rule{% #create-a-rule %}

1. To create a detection rule, navigate to the [Create a New Detection](https://app.datadoghq.com/security/configuration/siem/rules) page.
1. Select **Scheduled Rule**.

## Define your scheduled rule{% #define-your-scheduled-rule %}

Select the detection method you want to use for creating signals.

## Define search queries{% #define-search-queries %}

{% tab title="Threshold" %}
Choose the query language you want to use.

{% collapsible-section #threshold-event-query %}
#### Event Query

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/threshold_20250310.5ad2188a658fd5fb9c591f4570f334e3.png?auto=format"
   alt="Define the search query" /%}

1. To search Audit Trail events or events from Events Management, click the down arrow next to **Logs** and select **Audit Trail** or **Events**.

1. If you are an add-on and see the **Index** dropdown menu, select the index of logs you want to analyze.

1. Construct a search query for your logs or events using the [Log Explorer search syntax][1].

1. (Optional) In the **Count** dropdown menu, select attributes whose unique values are counted over the specified time frame.

1. (Optional) In the **group by** dropdown menu, select attributes you want to group by.

   - The defined `group by` generates a signal for each `group by` value.
   - Typically, the `group by` is an entity (like user, or IP). The `group by` is also used to join the queries together.
   - Joining logs that span a time frame can increase the confidence or severity of the security signal. For example, to detect a successful brute force attack, both successful and unsuccessful authentication logs must be correlated for a user.

1. (Optional) To create calculated fields that transform your logs during query time:

   1. Click **Add** and select **Calculated fields**.
   1. In **Name your field**, enter a descriptive name that indicates the purpose of the calculated field.
      - For example, if you want to combine users' first and last name into one field, you might name the calculated field `fullName`.
   1. In the **Define your formula** field, enter a formula or expression, which determines the result to be computed and stored as the value of the calculated field for each log event.
      - See [Calculated Fields Expressions Language](https://docs.datadoghq.com/logs/explorer/calculated_fields/expression_language/) for information on syntax and language constructs.

1. (Optional) To filter logs using reference tables:

   1. Click the **Add** button next to the query editor and select **Join with Reference Table**.
   1. In the **Inner join with reference table** dropdown menu, select your reference table.
   1. In the **where field** dropdown menu, select the log field to join on.
   1. Select the **IN** or **NOT IN** operator to filter in or filter out matching logs.
   1. In the **column** dropdown menu, select the column of the reference table to join on.

1. (Optional) To test your rules against sample logs, click **Unit Test**.

   1. To construct a sample log, you can:
      1. Navigate to [Log Explorer](https://app.datadoghq.com/logs) in a new window.
      1. In the search bar, enter the query you are using for the detection rule.
   1. Select one of the logs.
   1. Click the export button at the top right side of the log side panel, and then select **Copy**.
   1. Navigate back to the **Unit Test** modal, and then paste the log into the text box. Edit the sample as needed for your use case.
   1. Toggle the switch for **Query is expected to match based on the example event** to fit your use case.
   1. Click **Run Query Test**.

{% /collapsible-section %}

{% collapsible-section #threshold-sql %}
#### SQL

You can use SQL syntax to write detection rules for additional flexibility, consistency, and portability. For information on the available syntax, see [DDSQL Reference](https://docs.datadoghq.com/ddsql_reference/).

In Datadog, SQL queries are compatible with data stored in [datasets](https://app.datadoghq.com/security/configuration/datasets). You can create datasets to format data already stored in tables for the following data types:

- Logs
- Audit Trail logs
- Events
- Security signals
- Spans
- RUM events
- Product Analytics events
- Cloud Network data
- NetFlow data
- Reference tables
- Infrastructure tables

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/sql-query-example.e5927ee7ad318495b0c2dccefd23a158.png?auto=format"
   alt="Example of a SQL dataset and query" /%}

1. Under **Define Datasets**, choose one or more datasets to use in your query. In the dropdown, you can select an existing published dataset to either use or clone, or click the **New** icon to create a database from scratch.
   - If you chose an existing dataset and made changes, click **Update** to apply those changes to that dataset, or **Clone With Changes** to create a dataset with your changes applied.
   - If you created a dataset, click **Create** so you can use it in your rule.
1. Under **Write Queries**, enter one or more SQL queries. For more information, see [DDSQL Reference](https://docs.datadoghq.com/ddsql_reference/). Click **Preview** to see a list of matching results.

{% /collapsible-section %}

{% /tab %}

{% tab title="New Value" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/new_value_20250310.1481920276a722442fd96535404612d3.png?auto=format"
   alt="Define the search query" /%}

1. To search Audit Trail events or events from Events Management, click the down arrow next to **Logs** and select **Audit Trail** or **Events**.

1. If you are an add-on and see the **Index** dropdown menu, select the index of logs you want to analyze.

1. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax/).

1. In the **Detect new value** dropdown menu, select the attributes you want to detect.

   - For example, if you create a query for successful user authentication with the following settings:
     - **Detect new value** is `country`
     - **group by** is `user`
     - Learning duration is `after 7 days`Then, logs coming in over the next 7 days are evaluated with those configured values. If a log comes in with a new value after the learning duration (`7 days`), a signal is generated, and the new value is learned to prevent future signals with this value.
   - You can also identify users and entities using multiple **Detect new value** attributes in a single query.
     - For example, if you want to detect when a user signs in from a new device and from a country that they've never signed in from before, add `device_id` and `country_name` to the **Detect new value** field.

1. (Optional) Define a signal grouping in the **group by** dropdown menu.

   - The defined `group by` generates a signal for each `group by` value.
   - Typically, the `group by` is an entity (like user or IP address).

1. In the dropdown menu to the right of **group by**, select the learning duration.

1. (Optional) Define a signal grouping in the **group by** dropdown menu.

   - The defined `group by` generates a signal for each `group by` value.
   - Typically, the `group by` is an entity (like user or IP address).

1. In the dropdown menu to the right of **group by**, select the learning duration.

1. (Optional) To create calculated fields that transform your logs during query time:

   1. Click **Add** and select **Calculated fields**.
   1. In **Name your field**, enter a descriptive name that indicates the purpose of the calculated field.
      - For example, if you want to combine users' first and last name into one field, you might name the calculated field `fullName`.
   1. In the **Define your formula** field, enter a formula or expression, which determines the result to be computed and stored as the value of the calculated field for each log event.
      - See [Calculated Fields Expressions Language](https://docs.datadoghq.com/logs/explorer/calculated_fields/expression_language/) for information on syntax and language constructs.

1. (Optional) To filter logs using reference tables:

   1. Click the **Add** button next to the query editor and select **Join with Reference Table**.
   1. In the **Inner join with reference table** dropdown menu, select your reference table.
   1. In the **where field** dropdown menu, select the log field to join on.
   1. Select the **IN** or **NOT IN** operator to filter in or filter out matching logs.
   1. In the **column** dropdown menu, select the column of the reference table to join on.

1. (Optional) To test your rules against sample logs, click **Unit Test**.

   1. To construct a sample log, you can:
      1. Navigate to [Log Explorer](https://app.datadoghq.com/logs) in a new window.
      1. In the search bar, enter the query you are using for the detection rule.
   1. Select one of the logs.
   1. Click the export button at the top right side of the log side panel, and then select **Copy**.
   1. Navigate back to the **Unit Test** modal, and then paste the log into the text box. Edit the sample as needed for your use case.
   1. Toggle the switch for **Query is expected to match based on the example event** to fit your use case.
   1. Click **Run Query Test**.

{% /tab %}

{% tab title="Anomaly" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/anomaly_query.19923a9476fb314fd203d59d7ea8a3fb.png?auto=format"
   alt="Define the search query" /%}

1. To search Audit Trail events or events from Events Management, click the down arrow next to **Logs** and select **Audit Trail** or **Events**.

1. If you are an add-on and see the **Index** dropdown menu, select the index of logs you want to analyze.

1. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax/).

1. (Optional) In the **Count** dropdown menu, select attributes whose unique values you want to count during the specified time frame.

1. (Optional) In the **group by** dropdown menu, select attributes you want to group by.

   - The defined `group by` generates a signal for each `group by` value.
   - Typically, the `group by` is an entity (like user or IP). The `group by` can also join the queries together.
   - Joining logs that span a time frame can increase the confidence or severity of the security signal. For example, if you want to detect a successful brute force attack, both successful and unsuccessful authentication logs must be correlated for a user.
   - Anomaly detection inspects how the `group by` attribute has behaved in the past. If a `group by` attribute is seen for the first time (for example, the first time an IP is communicating with your system) and is anomalous, it does not generate a security signal because the anomaly detection algorithm has no historical data to compare with.

1. (Optional) To create calculated fields that transform your logs during query time:

   1. Click **Add** and select **Calculated fields**.
   1. In **Name your field**, enter a descriptive name that indicates the purpose of the calculated field.
      - For example, if you want to combine users' first and last name into one field, you might name the calculated field `fullName`.
   1. In the **Define your formula** field, enter a formula or expression, which determines the result to be computed and stored as the value of the calculated field for each log event.
      - See [Calculated Fields Expressions Language](https://docs.datadoghq.com/logs/explorer/calculated_fields/expression_language/) for information on syntax and language constructs.

1. (Optional) To filter logs using reference tables:

   1. Click the **Add** button next to the query editor and select **Join with Reference Table**.
   1. In the **Inner join with reference table** dropdown menu, select your reference table.
   1. In the **where field** dropdown menu, select the log field to join on.
   1. Select the **IN** or **NOT IN** operator to filter in or filter out matching logs.
   1. In the **column** dropdown menu, select the column of the reference table to join on.

1. (Optional) To test your rules against sample logs, click **Unit Test**.

   1. To construct a sample log, you can:
      1. Navigate to [Log Explorer](https://app.datadoghq.com/logs) in a new window.
      1. In the search bar, enter the query you are using for the detection rule.
   1. Select one of the logs.
   1. Click the export button at the top right side of the log side panel, and then select **Copy**.
   1. Navigate back to the **Unit Test** modal, and then paste the log into the text box. Edit the sample as needed for your use case.
   1. Toggle the switch for **Query is expected to match based on the example event** to fit your use case.
   1. Click **Run Query Test**.

{% /tab %}

{% tab title="Content Anomaly" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/content_anomaly_query.dfd62c07fd232437cb885823e91eb6e4.png?auto=format"
   alt="Define the search query" /%}

1. To search Audit Trail events or events from Events Management, click the down arrow next to **Logs** and select **Audit Trail** or **Events**.

1. If you are an add-on and see the **Index** dropdown menu, select the index of logs you want to analyze.

1. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax/).

1. In the **Detect anomaly** field, specify the fields whose values you want to analyze.

1. In the **group by** field, specify the fields you want to group by.

   - The defined `group by` generates a signal for each `group by` value.
   - Typically, the `group by` is an entity (like user or IP). The `group by` can also join the queries together.
   - Joining logs that span a time frame can increase the confidence or severity of the security signal. For example, to detect a successful brute force attack, both successful and unsuccessful authentication logs must be correlated for a user.

1. In the **Learn for** dropdown menu, select the number of days for the learning period. During the learning period, the rule sets a baseline of normal field values and does not generate any signals.

   - **Note**: If the detection rule is modified, the learning period restarts at day `0`.

1. (Optional) To create calculated fields that transform your logs during query time:

   1. Click **Add** and select **Calculated fields**.
   1. In **Name your field**, enter a descriptive name that indicates the purpose of the calculated field.
      - For example, if you want to combine users' first and last name into one field, you might name the calculated field `fullName`.
   1. In the **Define your formula** field, enter a formula or expression, which determines the result to be computed and stored as the value of the calculated field for each log event.
      - See [Calculated Fields Expressions Language](https://docs.datadoghq.com/logs/explorer/calculated_fields/expression_language/) for information on syntax and language constructs.

1. (Optional) To filter logs using reference tables:

   1. Click the **Add** button next to the query editor and select **Join with Reference Table**.
   1. In the **Inner join with reference table** dropdown menu, select your reference table.
   1. In the **where field** dropdown menu, select the log field to join on.
   1. Select the **IN** or **NOT IN** operator to filter in or filter out matching logs.
   1. In the **column** dropdown menu, select the column of the reference table to join on.

1. (Optional) To test your rules against sample logs, click **Unit Test**.

   1. To construct a sample log, you can:
      1. Navigate to [Log Explorer](https://app.datadoghq.com/logs) in a new window.
      1. In the search bar, enter the query you are using for the detection rule.
   1. Select one of the logs.
   1. Click the export button at the top right side of the log side panel, and then select **Copy**.
   1. Navigate back to the **Unit Test** modal, and then paste the log into the text box. Edit the sample as needed for your use case.
   1. Toggle the switch for **Query is expected to match based on the example event** to fit your use case.
   1. Click **Run Query Test**.

{% /tab %}

{% tab title="Impossible Travel" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/impossible_travel_query.764df6c2228f9605ccbeb97d45bf64f7.png?auto=format"
   alt="Define the search query" /%}

1. To search Audit Trail events or events from Events Management, click the down arrow next to **Logs** and select **Audit Trail** or **Events**.
1. If you are an add-on and see the **Index** dropdown menu, select the index of logs you want to analyze.
1. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax/).
1. In the **User attribute** dropdown menu, select the log attribute that contains the user ID. This can be an identifier like an email address, user name, or account identifier.
1. The **Location attribute** value is automatically set to `@network.client.geoip`.
   - The `location attribute` specifies which field holds the geographic information for a log.
   - The only supported value is `@network.client.geoip`, which is enriched by the [GeoIP parser](https://docs.datadoghq.com/logs/log_configuration/processors/?tab=ui#geoip-parser) to give a log location information based on the client's IP address.
1. Click the **Baseline user locations** checkbox if you want Datadog to learn regular access locations before triggering a signal.
   - When selected, signals are suppressed for the first 24 hours. During that time, Datadog learns the user's regular access locations. This can be helpful to reduce noise and infer VPN usage or credentialed API access.
   - See [How the impossible detection method works](https://docs.datadoghq.com/security/cloud_siem/detect_and_monitor/custom_detection_rules/impossible_travel/#how-the-impossible-travel-method-works) for more information.

1. (Optional) To create calculated fields that transform your logs during query time:

   1. Click **Add** and select **Calculated fields**.
   1. In **Name your field**, enter a descriptive name that indicates the purpose of the calculated field.
      - For example, if you want to combine users' first and last name into one field, you might name the calculated field `fullName`.
   1. In the **Define your formula** field, enter a formula or expression, which determines the result to be computed and stored as the value of the calculated field for each log event.
      - See [Calculated Fields Expressions Language](https://docs.datadoghq.com/logs/explorer/calculated_fields/expression_language/) for information on syntax and language constructs.

1. (Optional) To filter logs using reference tables:

   1. Click the **Add** button next to the query editor and select **Join with Reference Table**.
   1. In the **Inner join with reference table** dropdown menu, select your reference table.
   1. In the **where field** dropdown menu, select the log field to join on.
   1. Select the **IN** or **NOT IN** operator to filter in or filter out matching logs.
   1. In the **column** dropdown menu, select the column of the reference table to join on.

1. (Optional) To test your rules against sample logs, click **Unit Test**.

   1. To construct a sample log, you can:
      1. Navigate to [Log Explorer](https://app.datadoghq.com/logs) in a new window.
      1. In the search bar, enter the query you are using for the detection rule.
   1. Select one of the logs.
   1. Click the export button at the top right side of the log side panel, and then select **Copy**.
   1. Navigate back to the **Unit Test** modal, and then paste the log into the text box. Edit the sample as needed for your use case.
   1. Toggle the switch for **Query is expected to match based on the example event** to fit your use case.
   1. Click **Run Query Test**.

**Note**: All logs and events matching this query are analyzed for a potential impossible travel.
{% /tab %}

{% tab title="Third Party" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/third_party_query.ef079282a8c45974ca85c18334547cf8.png?auto=format"
   alt="Define the search query" /%}

1. To search Audit Trail events or events from Events Management, click the down arrow next to **Logs** and select **Audit Trail** or **Events**.

1. If you are an add-on and see the **Index** dropdown menu, select the index of logs you want to analyze.

1. Construct a root query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax/).

1. In the **Trigger for each new** dropdown menu, select the attributes where each attribute generates a signal for each new attribute value over 24-hour roll-up period.

1. (Optional) To create calculated fields that transform your logs during query time:

   1. Click **Add** and select **Calculated fields**.
   1. In **Name your field**, enter a descriptive name that indicates the purpose of the calculated field.
      - For example, if you want to combine users' first and last name into one field, you might name the calculated field `fullName`.
   1. In the **Define your formula** field, enter a formula or expression, which determines the result to be computed and stored as the value of the calculated field for each log event.
      - See [Calculated Fields Expressions Language](https://docs.datadoghq.com/logs/explorer/calculated_fields/expression_language/) for information on syntax and language constructs.

1. (Optional) To filter logs using reference tables:

   1. Click the **Add** button next to the query editor and select **Join with Reference Table**.
   1. In the **Inner join with reference table** dropdown menu, select your reference table.
   1. In the **where field** dropdown menu, select the log field to join on.
   1. Select the **IN** or **NOT IN** operator to filter in or filter out matching logs.
   1. In the **column** dropdown menu, select the column of the reference table to join on.

1. (Optional) To test your rules against sample logs, click **Unit Test**.

   1. To construct a sample log, you can:
      1. Navigate to [Log Explorer](https://app.datadoghq.com/logs) in a new window.
      1. In the search bar, enter the query you are using for the detection rule.
   1. Select one of the logs.
   1. Click the export button at the top right side of the log side panel, and then select **Copy**.
   1. Navigate back to the **Unit Test** modal, and then paste the log into the text box. Edit the sample as needed for your use case.
   1. Toggle the switch for **Query is expected to match based on the example event** to fit your use case.
   1. Click **Run Query Test**.

Click **Add Root Query** to add additional queries.
{% /tab %}

{% tab title="Signal Correlation" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/signal_correlation_query.59a0beeac3db5594e5dbd8e945444cda.png?auto=format"
   alt="Define the search query" /%}

1. Select a rule for **Rule a**.
1. Click the pencil icon to rename the rule.
1. Use the **correlated by** dropdown to define the correlating attribute.
   - You can select multiple attributes (maximum of 3) to correlate the selected rules.
1. Select a rule for **Rule b** in the second Rule editor's dropdown.
   - The attributes and sliding window time frame is automatically set to what was selected for **Rule a**.
1. Click the pencil icon to rename the rule.

{% /tab %}

## Set conditions{% #set-conditions %}

{% tab title="Threshold" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/condition_simple_then.f6b444aa6c435356bc58e5f73180dd8b.png?auto=format"
   alt="Set your conditions, severity, and notification recipients" /%}

1. If you have a single query, skip to step 2. If you have multiple queries, you can create a **Simple condition** or **Then condition**.
   - If you want to create a simple condition, leave the selection as is.
   - If you want to create a `then` condition, click **THEN condition**.
     - Use the **Then condition** when you want to trigger a signal if query A occurs and then query B occurs.
     - **Note**: The `then` operator can only be used on a single rule condition.
1. (Optional) Click the pencil icon next to **Condition 1** if you want to rename the condition. This name is appended to the rule name when a signal is generated.
1. In the **Set severity to** dropdown menu, select the appropriate severity level (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
1. If you are creating a **Simple condition**, enter the condition when a signal should be created. If you are creating a **Then condition**, enter the conditions required for a signal to be generated.
   - All rule conditions are evaluated as condition statements. Thus, the order of the conditions affects which notifications are sent because the first condition to match generates the signal. Click and drag your rule conditions to change their order.
   - A rule condition contains logical operations (`>`, `>=`, `<`, `&&`, `||`) to determine if a signal should be generated based on the event counts in the previously defined queries.
   - The ASCII lowercase query labels are referenced in this section. An example rule condition for query `a` is `a > 3`.
   - **Note**: The query label must precede the operator. For example, `a > 3` is allowed; `3 < a` is not allowed.
1. (Optional) In the **Add notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications/#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules/) to avoid manual edits to notification preferences for individual detection rules.

### Other parameters{% #other-parameters %}

#### 1. Rule multi-triggering{% #rule-multi-triggering-schedule-threshold %}

Configure how often you want to keep updating the same signal if new values are detected within a specified time frame. For example, the same signal updates if any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.
- After a signal is generated, the signal remains "open" if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal.
- A signal closes after the time exceeds the `maximum signal duration`, regardless of the query being matched. This time is calculated from the first seen timestamp.
- **Note**: The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.

#### 2. Decrease severity for non-production environments{% #decrease-severity-schedule-threshold %}

Toggle **Decrease severity for non-production environments** if you want to prioritize production environment signals over non-production signals.

- The severity of signals in non-production environments are decreased by one level from what is defined by the rule case.
- The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.

#### 3. Enable optional group by{% #enable-group-by-schedule-threshold %}

Toggle **Enable Optional Group By** section if you want to group events even when values are missing. If there is a missing value, a sample value is generated so that the log does not get excluded.
{% /tab %}

{% tab title="New Value" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/severity_notification.e8bbde3d25eac5442ab806986df2c96f.png?auto=format"
   alt="Set your severity and notification recipients" /%}

### Other parameters{% #other-parameters %}

#### 1. Forget value{% #forget-value-scheduled-new-value %}

In the **Forget Value** dropdown, select the number of days (**1**-**30 days**) after which the value is forgotten.

#### 2. Rule multi-triggering behavior{% #rule-multi-triggering-scheduled-new-value %}

Configure how often you want to keep updating the same signal if new values are detected within a specified time frame. For example, the same signal updates if any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.
- After a signal is generated, the signal remains "open" if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal.
- A signal closes after the time exceeds the `maximum signal duration`, regardless of the query being matched. This time is calculated from the first seen timestamp.
- **Note**: The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.

#### 3. Decrease severity for non-production environments{% #decrease-severity-scheduled-new-value %}

Toggle **Decrease severity for non-production environments** if you want to prioritize production environment signals over non-production signals.

- The severity of signals in non-production environments are decreased by one level from what is defined by the rule case.
- The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.

#### 4. Enable optional group by{% #enable-group-by-scheduled-new-value %}

Toggle **Enable Optional Group By** section if you want to group events even when values are missing. If there is a missing value, a sample value is generated so that the log does not get excluded.

#### 5. Enable instantaneous baseline

Toggle **Enable instantaneous baseline** if you want to build the baseline based on past events for the first event received.
{% /tab %}

{% tab title="Anomaly" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/severity_notification.e8bbde3d25eac5442ab806986df2c96f.png?auto=format"
   alt="Set your severity and notification recipients" /%}

1. In the **Set severity to** dropdown menu, select the appropriate severity level (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
1. (Optional) In the **Add notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications/#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules/) to manage notifications automatically, avoiding manual edits for each detection rule.

### Other parameters{% #other-parameters %}

#### 1. Rule multi-triggering{% #rule-multi-triggering-scheduled-anomaly %}

Configure how often you want to keep updating the same signal if new values are detected within a specified time frame. For example, the same signal updates if any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.
- After a signal is generated, the signal remains "open" if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal.
- A signal closes after the time exceeds the `maximum signal duration`, regardless of the query being matched. This time is calculated from the first seen timestamp.
- **Note**: The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.

#### 2. Decrease severity for non-production environments{% #decrease-severity-scheduled-anomaly %}

Toggle **Decrease severity for non-production environments** if you want to prioritize production environment signals over non-production signals.

- The severity of signals in non-production environments are decreased by one level from what is defined by the rule case.
- The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.

#### 3. Enable optional group by{% #enable-group-by-scheduled-anomaly %}

Toggle **Enable Optional Group By** section if you want to group events even when values are missing. If there is a missing value, a sample value is generated so that the log does not get excluded.
{% /tab %}

{% tab title="Content Anomaly" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/condition_content_anomaly.0c9944113fa88417e4fdb2425c4210da.png?auto=format"
   alt="Set your condition, severity, and notification recipients" /%}

1. (Optional) Click the pencil icon next to **Condition 1** if you want to rename the condition. This name is appended to the rule name when a signal is generated.
1. In the **Set severity to** dropdown menu, select the appropriate severity level (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
1. In the **Anomaly count** field, enter the condition for how many anomalous logs within the specified window are required to trigger a signal.
   - For example, if the condition is `a >= 3` where `a` is the query, a signal is triggered if there are at least three anomalous logs within the evaluation window.
   - All rule conditions are evaluated as condition statements. Thus, the order of the conditions affects which notifications are sent because the first condition to match generates the signal. Click and drag your rule conditions to change their ordering.
   - A rule condition contains logical operations (`>`, `>=`, `&&`, `||`) to determine if a signal should be generated based on the event counts in the previously defined queries.
   - The ASCII lowercase query labels are referenced in this section. An example rule condition for query `a` is `a > 3`.
   - **Note**: The query label must precede the operator. For example, `a > 3` is allowed; `3 < a` is not allowed.
1. In the **within a window of** dropdown menu, select the time period during which a signal is triggered if the condition is met.
   - An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.
1. In the **Add notify** section, click **Add Recipient** to optionally configure [notification targets](https://docs.datadoghq.com/security_platform/notifications/#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules/) to avoid manual edits to notification preferences for individual detection rules.

### Other parameters{% #other-parameters %}

#### 1. Content anomaly detection{% #content-anomaly-scheduled-content-anomaly %}

In the **Content anomaly detection options** section, specify the parameters to assess whether a log is anomalous or not.

- Content anomaly detection balances precision and sensitivity using several rule parameters that you can set:
  1. Similarity threshold: Defines how dissimilar a field value must be to be considered anomalous (default: `70%`).
  1. Minimum similar items: Sets how many similar historical logs must exist for a value to be considered normal (default: `1`).
  1. Evaluation window: The time frame during which anomalies are counted toward a signal (for example, a 10-minute time frame).
- These parameters help to identify field content that is both unusual and rare, filtering out minor or common variations.
- See [Anomaly detection parameters](https://docs.datadoghq.com/security/cloud_siem/detect_and_monitor/custom_detection_rules/content_anomaly/#anomaly-detection-parameters) for more information.

#### 2. Rule multi-triggering behavior{% #rule-multi-triggering-scheduled-content-anomaly %}

Configure how often you want to keep updating the same signal if new values are detected within a specified time frame. For example, the same signal updates if any new value is detected within 1 hour, for a maximum duration of 24 hours.

- After a signal is generated, the signal remains "open" if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal.
- A signal closes after the time exceeds the `maximum signal duration`, regardless of the query being matched. This time is calculated from the first seen timestamp.
- **Note**: The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.

#### 3. Decrease severity for non-production environments{% #decrease-severity-scheduled-content-anomaly %}

Toggle **Decrease severity for non-production environments** if you want to prioritize production environment signals over non-production signals.

- The severity of signals in non-production environments are decreased by one level from what is defined by the rule case.
- The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.

#### 4. Enable optional group by{% #enable-group-by-scheduled-content-anomaly %}

Toggle **Enable Optional Group By** section if you want to group events even when values are missing. If there is a missing value, a sample value is generated so that the log does not get excluded.
{% /tab %}

{% tab title="Impossible Travel" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/severity_notification.e8bbde3d25eac5442ab806986df2c96f.png?auto=format"
   alt="Set your severity and notification recipients" /%}

1. In the **Set severity to** dropdown menu, select the appropriate severity level (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
1. (Optional) In the **Add notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications/#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules/) to manage notifications automatically, avoiding manual edits for each detection rule.

### Other parameters{% #other-parameters %}

#### 1. Rule multi-triggering{% #rule-multi-triggering-scheduled-impossible-travel %}

Configure how often you want to keep updating the same signal if new values are detected within a specified time frame. For example, the same signal updates if any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.
- After a signal is generated, the signal remains "open" if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal.
- A signal closes after the time exceeds the `maximum signal duration`, regardless of the query being matched. This time is calculated from the first seen timestamp.
- **Note**: The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.

#### 2. Decrease severity for non-production environments{% #decrease-severity-scheduled-impossible-travel %}

Toggle **Decrease severity for non-production environments** if you want to prioritize production environment signals over non-production signals.

- The severity of signals in non-production environments are decreased by one level from what is defined by the rule case.
- The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.

#### 3. Enable optional group by{% #enable-group-by-scheduled-impossible-travel %}

Toggle **Enable Optional Group By** section if you want to group events even when values are missing. If there is a missing value, a sample value is generated so that the log does not get excluded.
{% /tab %}

{% tab title="Third Party" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/condition_else.b7196e7931f3562be1d01fc5eadb83be.png?auto=format"
   alt="Set your conditions, severity, and notification recipients" /%}

1. (Optional) Click the pencil icon next to **Condition 1** if you want to rename the condition. This name is appended to the rule name when a signal is generated.
1. In the **Set severity to** dropdown menu, select the appropriate severity level (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
1. In the **Query** field, enter the tags of a log that you want to trigger a signal.
   - For example, if you want logs with the tag `dev:demo` to trigger signals with a severity of `INFO`, enter `dev:demo` in the query field. Similarly, if you want logs with the tag `dev:prod` to trigger signals with a severity of `MEDIUM`, enter `dev:prod` in the query field.
1. (Optional) In the **Add notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications/#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules/) to avoid manual edits to notification preferences for individual detection rules.
1. For the `else` condition, follow steps 3 and 4.
   - The `else` condition is the default condition. If you don't add any other conditions, then all logs trigger a signal with the severity set in the default condition.

### Other parameters{% #other-parameters %}

#### 1. Decrease severity for non-production environments{% #decrease-severity-scheduled-third-party %}

Toggle **Decrease severity for non-production environments** if you want to prioritize production environment signals over non-production signals.

- The severity of signals in non-production environments are decreased by one level from what is defined by the rule case.
- The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.

#### 2. Enable optional group by{% #enable-group-by-scheduled-third-party %}

Toggle **Enable Optional Group By** section if you want to group events even when values are missing. If there is a missing value, a sample value is generated so that the log does not get excluded.
{% /tab %}

{% tab title="Signal Correlation" %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/condition_simple_then.f6b444aa6c435356bc58e5f73180dd8b.png?auto=format"
   alt="Set your conditions, severity, and notification recipients" /%}

1. If you want to create a simple condition, leave the selection as is. If you want to create a `then` condition, click **THEN condition**.
   - Use the **Then condition** when you want to trigger a signal if query A occurs and then query B occurs.
   - **Note**: The `then` operator can only be used on a single rule condition.
1. (Optional) Click the pencil icon next to **Condition 1** if you want to rename the condition. This name is appended to the rule name when a signal is generated.
1. In the **Set severity to** dropdown menu, select the appropriate severity level (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
1. If you are creating a **Simple condition**, enter the condition when a signal should be created. If you are creating a **Then condition**, enter the conditions required for a signal to be generated.
   - All rule conditions are evaluated as conditional statements. Thus, the order of the conditions affects which notifications are sent because the first condition to match generates the signal. Click and drag your rule conditions to change their order.
   - A rule condition contains logical operations (`>`, `>=`, `<`, `&&`, `||`) to determine if a signal should be generated based on the event counts in the previously defined queries.
   - The ASCII lowercase query labels are referenced in this section. An example rule condition for query `a` is `a > 3`.
   - **Note**: The query label must precede the operator. For example, `a > 3` is allowed; `3 < a` is not allowed.
1. In the **Add notify** section, click **Add Recipient** to optionally configure [notification targets](https://docs.datadoghq.com/security_platform/notifications/#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules/) to manage notifications automatically, avoiding manual edits for each detection rule.

### Other parameters{% #other-parameters %}

#### 1. Rule multi-triggering{% #rule-multi-triggering-scheduled-signal-correlation %}

Configure how often you want to keep updating the same signal if new values are detected within a specified time frame. For example, the same signal updates if any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.
- After a signal is generated, the signal remains "open" if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal.
- A signal closes after the time exceeds the `maximum signal duration`, regardless of the query being matched. This time is calculated from the first seen timestamp.
- **Note**: The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.

#### 2. Decrease severity for non-production environments{% #decrease-severity-scheduled-signal-correlation %}

Toggle **Decrease severity for non-production environments** if you want to prioritize production environment signals over non-production signals.

- The severity of signals in non-production environments are decreased by one level from what is defined by the rule case.
- The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.

{% /tab %}

## Add custom schedule{% #add-custom-schedule %}

You can set specific evaluation time and how often it runs by creating a custom schedule or using a recurrence rule (RRULE).

### Create custom schedule{% #create-custom-schedule %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/custom_schedule.92463bc6d364247473acfc84056854fd.png?auto=format"
   alt="The Use custom schedule section with an example" /%}

1. Select **Create Custom Schedules**.
1. Set how often and at what time you want the rule to run.

### Use RRULE{% #use-rrule %}

{% image
   source="https://datadog-docs.imgix.net/images/security/security_monitoring/detection_rules/rrule_example.521c960776b9de3f50ebb1b19ceb2fd5.png?auto=format"
   alt="The Use RRULE section with an example" /%}

Recurrence rule (RRULE) is a property name from the [iCalendar RFC](https://icalendar.org/rrule-tool.html), which is the standard for defining recurring events. Use the [official RRULE generator](https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html) to generate recurring rules. Leverage RRULEs to cover more advanced scheduling use cases.

For example, if the RRULE is:

```text
FREQ=DAILY;INTERVAL=1;BYHOUR=6;BYMINUTE=0
```

The example RRULE runs the scheduled rule once a day at 6:00 AM.

**Notes**:

- Attributes specifying the duration in RRULE are not supported (for example, `DTSTART`, `DTEND`, `DURATION`).
- Evaluation frequencies must be a day or longer. For shorter evaluation frequencies, use the default monitor schedules.

To write a custom RRULE for your detection rule:

1. Select **</> Use RRULE**.
1. Set the date and time for when you want the rule to start.
1. Input a [RRULE string](https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html) to set how often you want the rule to run.

## Describe your playbook{% #describe-your-playbook %}

1. Enter a **Rule name**. The name appears in the detection rules list view and the title of the security signal.
1. In the **Rule message** section, use [notification variables](https://docs.datadoghq.com/security_platform/notifications/variables/) and Markdown to customize the notifications sent when a signal is generated.
   - You can use [template variables](https://docs.datadoghq.com/security_platform/notifications/variables/#template-variables) in the notification to inject dynamic context from triggered logs directly into a security signal and its associated notifications.
   - See the [Notification Variables documentation](https://docs.datadoghq.com/security_platform/notifications/variables/) for more information and examples.
1. Use the **Tag resulting signals** dropdown menu to add tags to your signals. For example, `security:attack` or `technique:T1110-brute-force`.
   - **Note**: the tag `security` is special. This tag is used to classify the security signal. The recommended options are: `attack`, `threat-intel`, `compliance`, `anomaly`, and `data-leak`.

## Create a suppression{% #create-a-suppression %}

(Optional) Create a suppression or add the rule to an existing suppression to prevent a signal from getting generated in specific cases. For example, if a user `john.doe` is triggering a signal, but their actions are benign and you do not want signals triggered from this user, add the following query into the **Add a suppression query** field: `@user.username:john.doe`.

#### Create new suppression{% #create-new-suppression %}

1. Enter a name for the suppression rule.
1. (Optional) Enter a description.
1. Enter a suppression query.
1. (Optional) Add a log exclusion query to exclude logs from being analyzed. These queries are based on **log attributes**.
   - **Note**: The legacy suppression was based on log exclusion queries, but it is now included in the suppression rule's **Add a suppression query** step.

#### Add to existing suppression{% #add-to-existing-suppression %}

1. Click **Add to Existing Suppression**.
1. Select an existing suppression in the dropdown menu.