---
title: Create a Custom 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
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Create a Custom Rule

## Overview{% #overview %}

### Understand rule creation options{% #understand-rule-creation-options %}

Before creating a rule, you must choose three options:

{% collapsible-section #detection-methods %}
#### Detection method

The event to monitor for:

{% dl %}

{% dt %}
**Threshold**
{% /dt %}

{% dd %}
Detects when a query for a specific activity occurs a number of times you define. Set the threshold to 1 for signature-based detections, or use a higher value to alert on patterns of alerted activity. This is the most common starting point when building a rule.
{% /dd %}

{% dt %}
**New Value**
{% /dt %}

{% dd %}
Triggers when one or more tracked attributes take on a value not seen during the learning period; for example, an account logging in from a country, IP, and device it's never used before.
{% /dd %}

{% dt %}
**Anomaly**
{% /dt %}

{% dd %}
Detects unexpected spikes or upward shifts, but not drop-offs, in log activity, accounting for daily and weekly seasonality. An example detection could be a spike in outbound traffic from a database server at 2 PM, far outside its normal nightly backup window.
{% /dd %}

{% dt %}
**Content Anomaly**
{% /dt %}

{% dd %}
Attackers hide intent in fields the rest of the log looks normal in; for example, encoded commands, oddly long URLs, or suspicious user agents. Content Anomaly inspects those fields and flags content that doesn't match what you usually see.
{% /dd %}

{% dt %}
**Impossible Travel**
{% /dt %}

{% dd %}
If a user signs in from New York and London 10 minutes apart, at least one of those sessions isn't theirs. Impossible Travel detects credential theft by comparing the speed required to move between consecutive logins.
{% /dd %}

{% dt %}
**Third Party**
{% /dt %}

{% dd %}
Your security stack already detects threats in your endpoint, identity, and cloud tools. Third Party brings those findings into Cloud SIEM so they can be triaged alongside your native rules, in a single, unified workflow.
{% /dd %}

{% dt %}
**Sequence**
{% /dt %}

{% dd %}
A sequence of events that are suspicious in combination with each other: for example, a successful login from a previously unseen IP, then a new privileged role granted to that user, then access to a sensitive resource, all in that order, by the same actor. Each step on its own can look like normal admin activity. Only the precise chain points to credential abuse.
{% /dd %}

{% /dl %}

{% /collapsible-section %}

{% collapsible-section #rule-types %}
#### Rule type

When you want to analyze incoming or indexed events:

{% dl %}

{% dt %}
**Real-time rule**
{% /dt %}

{% dd %}
Real-time detection rules continuously monitor and analyze incoming logs for security threats. These rules trigger immediate alerts when specific patterns or anomalies are detected, enabling quicker response to potential incidents.
{% /dd %}

{% dt %}
**Scheduled rule**
{% /dt %}

{% dd %}
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. They complement real-time monitoring by providing periodic, in-depth analysis of logs using [calculated fields](https://docs.datadoghq.com/logs/explorer/calculated_fields.md).
{% /dd %}

{% dt %}
**Historical job**
{% /dt %}

{% dd %}
Historical jobs are one-time executable queries on historical logs used to backtest detection rules and assess their effectiveness on past data. The generated job results are lightweight versions of signals providing information on potential threats and anomalies on historical logs. After reviewing the results, you can convert results needing immediate action into signals.
{% /dd %}

{% /dl %}

{% /collapsible-section %}

{% collapsible-section #query-languages %}
#### Query language

The language used to write your query:

{% dl %}

{% dt %}
**Event query**
{% /dt %}

{% dd %}
Depending on the detection method and rule type, you can create detections based on data in logs, audit trails, events, RUM, signals, or rules.
{% /dd %}

{% dt %}
**SQL**
{% /dt %}

{% dd %}
Use SQL syntax to write detection rules using [DDSQL](https://docs.datadoghq.com/ddsql_reference.md) that are compatible with datasets.
{% /dd %}

{% dt %}
**Event/rule query**
{% /dt %}

{% dd %}
If you select the Sequence detection method, for each step in the sequence, you can query logs using either events or rules.
{% /dd %}

{% /dl %}

{% /collapsible-section %}

The options you choose impact the steps required to create the rule. Use the filters at the top of this page to specify your rule creation options, so the relevant instructions populate on the rest of the page.

| **Detection method**  | **Rule types**     |
| --------------------- | ------------------ |
| **Real-time rule**    | **Scheduled rule** | **Historical job** |
| **Threshold**         | Event query        | Event query, SQL   |
| **New Value**         | Event query        |
| **Anomaly**           |
| **Content anomaly**   |
| **Impossible travel** |
| **Third party**       |
| **Sequence**          | Event/rule query   | *Not supported*    | Event/rule query |

If you're getting started, you can click these links to automatically apply common filter combinations to this page:

- Threshold/Real-time rule/Event query
- Threshold/Scheduled rule/SQL
- Threshold/Historical job/SQL

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

1. To create a detection rule, navigate to the [Create a New Detection](https://app.datadoghq.com/security/siem/rules/new) page.
1. {% section displayed-if="Detection method is Threshold" %}
This section only applies to users who meet the following criteria: Detection method is Threshold
Select the **Threshold** detection method.   {% /section %}

   {% section displayed-if="Detection method is New value" %}
This section only applies to users who meet the following criteria: Detection method is New value
Select the **New value** detection method.   {% /section %}

   {% section displayed-if="Detection method is Anomaly" %}
This section only applies to users who meet the following criteria: Detection method is Anomaly
Select the **Anomaly** detection method.   {% /section %}

   {% section displayed-if="Detection method is Content anomaly" %}
This section only applies to users who meet the following criteria: Detection method is Content anomaly
Select the **Content Anomaly** detection method.   {% /section %}

   {% section displayed-if="Detection method is Impossible travel" %}
This section only applies to users who meet the following criteria: Detection method is Impossible travel
Select the **Impossible travel** detection method.   {% /section %}

   {% section displayed-if="Detection method is Third party" %}
This section only applies to users who meet the following criteria: Detection method is Third party
Select the **Third party** detection method.   {% /section %}

   {% section displayed-if="Detection method is Sequence" %}
This section only applies to users who meet the following criteria: Detection method is Sequence
Select the **Sequence** detection method.   {% /section %}
1. {% section
      displayed-if="((Detection method is Threshold) or (Detection method is New value) or (Detection method is Anomaly) or (Detection method is Content anomaly) or (Detection method is Impossible travel) or (Detection method is Third party)) and (Rule type is Real-time rule)" %}
This section only applies to users who meet the following criteria: ((Detection method is Threshold) or (Detection method is New value) or (Detection method is Anomaly) or (Detection method is Content anomaly) or (Detection method is Impossible travel) or (Detection method is Third party)) and (Rule type is Real-time rule)
Select **Real-Time Rule**, which also automatically selects **Event query** as the query language.   {% /section %}

   {% section
      displayed-if="((Detection method is New value) or (Detection method is Anomaly) or (Detection method is Content anomaly) or (Detection method is Impossible travel) or (Detection method is Third party)) and (Rule type is Scheduled rule)" %}
This section only applies to users who meet the following criteria: ((Detection method is New value) or (Detection method is Anomaly) or (Detection method is Content anomaly) or (Detection method is Impossible travel) or (Detection method is Third party)) and (Rule type is Scheduled rule)
Select **Scheduled Rule**, which also automatically selects **Event query** as the query language.   {% /section %}

   {% section
      displayed-if="((Detection method is New value) or (Detection method is Anomaly) or (Detection method is Content anomaly) or (Detection method is Impossible travel) or (Detection method is Third party)) and (Rule type is Historical job)" %}
This section only applies to users who meet the following criteria: ((Detection method is New value) or (Detection method is Anomaly) or (Detection method is Content anomaly) or (Detection method is Impossible travel) or (Detection method is Third party)) and (Rule type is Historical job)
Select **Historical Job**, which also automatically selects **Event query** as the query language. Under **Select Logs Index and Timerange**, select the parameters for your historical query.   {% /section %}

   {% section
      displayed-if="(Detection method is Threshold) and (Rule type is Scheduled rule) and (Query language is Event query)" %}
This section only applies to users who meet the following criteria: (Detection method is Threshold) and (Rule type is Scheduled rule) and (Query language is Event query)
Select **Scheduled Rule**, then **Event query**.   {% /section %}

   {% section
      displayed-if="(Detection method is Threshold) and (Rule type is Scheduled rule) and (Query language is SQL)" %}
This section only applies to users who meet the following criteria: (Detection method is Threshold) and (Rule type is Scheduled rule) and (Query language is SQL)
Select **Scheduled Rule**, then **SQL**.   {% /section %}

   {% section
      displayed-if="(Detection method is Threshold) and (Rule type is Historical job) and (Query language is Event query)" %}
This section only applies to users who meet the following criteria: (Detection method is Threshold) and (Rule type is Historical job) and (Query language is Event query)
Select **Historical Job**, then **Event query**. Under **Select Logs Index and Timerange**, select the parameters for your historical query.   {% /section %}

   {% section
      displayed-if="(Detection method is Threshold) and (Rule type is Historical job) and (Query language is SQL)" %}
This section only applies to users who meet the following criteria: (Detection method is Threshold) and (Rule type is Historical job) and (Query language is SQL)
Select **Historical Job**, then **SQL**. Under **Select Timerange**, select the time window for your historical query.   {% /section %}

   {% section
      displayed-if="(Detection method is Sequence) and (Rule type is Real-time rule)" %}
This section only applies to users who meet the following criteria: (Detection method is Sequence) and (Rule type is Real-time rule)
Select **Real-time rule**, which also automatically selects **Event/rule query** as the query language.   {% /section %}

   {% section
      displayed-if="(Detection method is Sequence) and (Rule type is Historical job)" %}
This section only applies to users who meet the following criteria: (Detection method is Sequence) and (Rule type is Historical job)
Select **Historical job**, which also automatically selects **Event/rule query** as the query language. Under **Select Logs Index and Timerange**, select the parameters for your historical query.   {% /section %}

{% section displayed-if="Query language is SQL" %}
This section only applies to users who meet the following criteria: Query language is SQL

## Use datasets in your query{% #use-datasets-in-your-query %}

In Datadog, SQL queries are compatible with data stored in [datasets](https://app.datadoghq.com/security/configuration/datasets).

- **Datasets** are reusable resources that specify the field names and types for a given source. When writing a SQL detection rule, you reference a dataset instead of defining the schema inline, making it faster to write new rules and easier to maintain them over time.
- **OOTB OCSF datasets** are built-in datasets provided by Datadog for all log sources. They are normalized to the Open Cybersecurity Schema Framework (OCSF), including AWS CloudTrail, Okta, Microsoft 365, and others. These are automatically available in all organizations, so teams writing SQL rules against OCSF-normalized sources can skip schema definitions entirely. Each OOTB OCSF dataset corresponds with an [OCSF v1.7.0 schema category](https://schema.ocsf.io/1.7.0/).

If you have the [Security Dataset Write](https://docs.datadoghq.com/account_management/rbac/permissions.md#cloud-security-platform) permission, you can create custom 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

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

To create a custom dataset:

1. In Datadog, go to Cloud SIEM > Settings > [Datasets](https://app.datadoghq.com/security/configuration/datasets).
1. Click Create Dataset. In the Create Dataset window that opens, enter the following:
   - Enter an optional Description.
   - Replace `my_new_dataset` with a Name.
   - Under Select columns, search for and select the columns you want in your dataset.
   - Beside each column name in your dataset, you can click the More options button to move the column's position in the dataset. Alternatively, you can click Edit column to edit the column's path, add an alias, and data type.
1. Click Create Dataset. The Create Dataset window closes and the dataset appears in your list of security datasets.

### Delete or edit a dataset{% #delete-or-edit-a-dataset %}

{% alert level="info" %}

- You can delete or edit custom datasets, but not OOTB OCSF datasets.
- You can only delete datasets that aren't used in any detection rules.

{% /alert %}

1. In Datadog, go to Cloud SIEM > Settings > [Datasets](https://app.datadoghq.com/security/configuration/datasets).
1. Beside the dataset you want to delete or edit, click the More options button.
   - To delete the dataset, click Delete. In the confirmation window that opens, click Delete.
   - To view detection rules that use this dataset, click the View dependent detection rules count. If you want to delete the dataset, you must delete these rules or use a different dataset for them first.
   - To edit the dataset, click **See details**. In the Reviewing Dataset panel that opens, click **Edit Dataset**. Make the required changes, then click **Save Changes**.
     - Every time you edit a dataset, Datadog saves the old version in the dataset's version history. In the Reviewing Dataset panel, you can compare versions and copy the source JSON for any version.
{% /section %}

## Define your search query{% #define-your-search-query %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Threshold)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Threshold)

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   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) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is New value)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is New value)

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   1. In the **Detect new value** dropdown menu, select the attributes you want to detect.
      - For example, you can 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) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Anomaly)

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
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 **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) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Content anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Content anomaly)

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   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.Important alert (level: info): 
If the detection rule is modified, the learning period restarts at day `0`.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Impossible travel)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Impossible travel)

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

{% alert level="info" %}
All logs and events matching this query are analyzed for potential impossible travel.
{% /alert %}

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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   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.md?tab=ui#geoip-parser) to give a log location information based on the client's IP address.
   1. Select 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.md#how-the-impossible-travel-method-works) for more information.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Third party)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Third party)

{% image
   source="https://docs.dd-static.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. Construct a root query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
1. In the **Trigger for each new** dropdown menu, select the attributes where each attribute generates a signal for each new attribute value over a 24-hour roll-up period.
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**.
1. Click **Add Root Query** and repeat steps 2-4 to add and test additional queries.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Sequence)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Sequence)

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sequence/sequence_queries.45e05b16842f0b49425697f5db45de45.png?auto=format"
   alt="Sequence editor page showing the sequence with two steps" /%}

### Add step{% #add-step %}

1. To search a different data type, click the down arrow next to **Logs** and select **Signals** or **Rules**.
1. Define the condition for the step.
   - **Logs**: Construct a search query using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   - **Signals**: Reference an existing rule or query on signal fields.
   - **Rules**: Select a rule.
1. Set **group by** fields (for example, `@usr.email` or `@ip.address`) to link entities across steps.
1. Enter a threshold condition, such as `>10`.
1. If you want to use another query, connect this query with the next query using `AND` or `OR` and repeat steps 1-4.
1. In the **roll-up over** dropdown menu, select the time frame all queries in that step must occur to transition to the next step.

### Define step transitions{% #define-step-transitions %}

For the current step and the next step:

1. In the **within** dropdown menu, select an evaluation window for the transition.Important alert (level: info): 
The total evaluation time across the sequence can be up to 24 hours.

1. Follow the instructions in Add step to complete the step.Important alert (level: info): 
You can select different `group by` fields between steps. For example, link `@usr.email` from an earlier step to `@ip.address` in a later step.

1. Click **Add Step** if you want to add more steps.

### Severity and notification{% #severity-and-notification %}

1. In the **Trigger** dropdown menu, select the severity status.
1. (Optional) In the **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

### Review the sequence preview{% #review-the-sequence-preview %}

1. In the **Preview detection** section, check the steps, transitions, and time window in the visualization of the steps. Reorder the steps and adjust time windows as needed.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Threshold)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Threshold)

{% section displayed-if="Query language is Event query" %}
This section only applies to users who meet the following criteria: Query language is Event query

{% image
   source="https://docs.dd-static.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 using 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.md).
   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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section displayed-if="Query language is SQL" %}
This section only applies to users who meet the following criteria: Query language is 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.md).

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sql-ocsf-query-example.57acebbe6b89363bb6b680e120110267.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 dataset 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.md). Click **Preview** to see a list of matching results.

Datadog applies rule conditions to the results your SQL queries return. It evaluates each query result against the conditions you define in the rule conditions section, such as a count threshold or group-by attribute. It generates a signal when the query results meet those conditions.
{% /section %}
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is New value)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is New value)

{% image
   source="https://docs.dd-static.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 using 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.md).
   1. In the **Detect new value** dropdown menu, select the attributes you want to detect.
      - For example, you can 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) 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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Anomaly)

{% image
   source="https://docs.dd-static.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 using 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.md).
   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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Content anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Content anomaly)

{% image
   source="https://docs.dd-static.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 using 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.md).
   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.Important alert (level: info): 
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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Impossible travel)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Impossible travel)

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

{% alert level="info" %}
All logs and events matching this query are analyzed for potential impossible travel.
{% /alert %}

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 using 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.md).
   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.md?tab=ui#geoip-parser) to give a log location information based on the client's IP address.
   1. Select 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.md#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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Third party)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Third party)

{% image
   source="https://docs.dd-static.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 using 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.md).
1. In the **Trigger for each new** dropdown menu, select the attributes where each attribute generates a signal for each new attribute value over a 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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Add Root Query** and repeat steps 3-7 to add and test additional queries.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Threshold)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Threshold)

{% section displayed-if="Query language is Event query" %}
This section only applies to users who meet the following criteria: Query language is Event query

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section displayed-if="Query language is SQL" %}
This section only applies to users who meet the following criteria: Query language is SQL

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

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sql-ocsf-query-example.57acebbe6b89363bb6b680e120110267.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 dataset 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.md). Click **Preview** to see a list of matching results.

Datadog applies conditions to the results your SQL queries return. It evaluates each query result against the conditions you define in the job conditions section, such as a count threshold or group-by attribute. It generates a job result when the query results meet those conditions.

{% alert level="info" %}
Historical jobs contain information from when the job ran and do not update automatically. When you view a job result that was detected using a SQL query, in the Queries section of the side panel, you can click the dataset to see when the dataset was last updated.

If the dataset was updated after the job result was created, you need to run the historical job again to get updated job results.
{% /alert %}
{% /section %}
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is New value)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is New value)

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   1. In the **Detect new value** dropdown menu, select the attributes you want to detect.
      - For example, you can 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) 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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Anomaly)

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Content anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Content anomaly)

{% image
   source="https://docs.dd-static.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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   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.Important alert (level: info): 
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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Impossible travel)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Impossible travel)

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

{% alert level="info" %}
All logs and events matching this query are analyzed for potential impossible travel.
{% /alert %}

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. Construct a search query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   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.md?tab=ui#geoip-parser) to give a log location information based on the client's IP address.
   1. Select 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.md#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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Third party)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Third party)

{% image
   source="https://docs.dd-static.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. Construct a root query for your logs or events using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
1. In the **Trigger for each new** dropdown menu, select the attributes where each attribute generates a signal for each new attribute value over a 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.md) for information on syntax and language constructs.
1. (Optional) 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**.
1. Click **Add Root Query** and repeat steps 2-6 to add and test additional queries.
1. Click **Save Rule**.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Sequence)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Sequence)

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sequence/sequence_queries.45e05b16842f0b49425697f5db45de45.png?auto=format"
   alt="Sequence editor page showing the sequence with two steps" /%}

### Add step{% #add-step-2 %}

1. To search a different data type, click the down arrow next to **Logs** and select **Signals** or **Rules**.
1. Define the condition for the step.
   - **Logs**: Construct a search query using the [Log Explorer search syntax](https://docs.datadoghq.com/logs/search_syntax.md).
   - **Signals**: Reference an existing rule or query on signal fields.
   - **Rules**: Select a rule.
1. Set **group by** fields (for example, `@usr.email` or `@ip.address`) to link entities across steps.
1. Enter a threshold condition, such as `>10`.
1. If you want to use another query, connect this query with the next query using `AND` or `OR` and repeat steps 1-4.
1. In the **roll-up over** dropdown menu, select the time frame all queries in that step must occur to transition to the next step.

### Define step transitions{% #define-step-transitions-2 %}

For the current step and the next step:

1. In the **within** dropdown menu, select an evaluation window for the transition.Important alert (level: info): 
The total evaluation time across the sequence can be up to 24 hours.

1. Follow the instructions in Add step to complete the step.Important alert (level: info): 
You can select different `group by` fields between steps. For example, link `@usr.email` from an earlier step to `@ip.address` in a later step.

1. Click **Add Step** if you want to add more steps.

### Severity and notification{% #severity-and-notification-2 %}

1. In the **Trigger** dropdown menu, select the severity status.
1. (Optional) In the **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

### Review the sequence preview{% #review-the-sequence-preview-2 %}

1. In the **Preview detection** section, check the steps, transitions, and time window in the visualization of the steps. Reorder the steps and adjust time windows as needed.
1. Click **Save Rule**.
{% /section %}

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

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Threshold)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Threshold)

{% image
   source="https://docs.dd-static.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.Important alert (level: info): 
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`.Important alert (level: info): 
The query label must precede the operator. For example, `a > 3` is allowed; `3 < a` is not allowed.
1. (Optional) In the **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to avoid manual edits to notification preferences for individual detection rules.

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

#### Rule multi-triggering{% #rule-multi-triggering-rt-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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Decrease severity for non-production environments{% #decrease-severity-rt-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`.

#### Enable optional group by{% #enable-group-by-rt-threshold %}

Toggle the **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.

#### Group signals{% #group-signals-rt-threshold %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is New value)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is New value)

{% image
   source="https://docs.dd-static.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 **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

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

#### Forget value{% #forget-value-rt-new-value %}

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

#### Rule multi-triggering behavior{% #rule-multi-triggering-rt-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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Decrease severity for non-production environments{% #decrease-severity-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`.

#### Enable optional group by{% #enable-group-by-rt-new-value %}

Toggle the **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.

#### Group signals{% #group-signals-rt-new-value %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.

#### Enable instantaneous baseline{% #enable-instantaneous-baseline-new-value %}

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

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Anomaly)

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/anomaly_notification.b3c96ac2be10c2ecc254ae1a65ba7ed9.png?auto=format"
   alt="Set your severity, anomaly percentile, and notification recipients" /%}

1. In the **Set severity to** dropdown menu, select the appropriate severity level (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
1. In the **Anomaly Percentile** dropdown menu, select a minimum percentage required for Cloud SIEM to generate a signal.The anomaly percentile refers to the log volume over the selected time period in comparison to your historical log volumes. If you select 99.5%, then Cloud SIEM only generates a signal if the number of logs for the current period is greater than 99.5% of all prior periods.
1. (Optional) In the **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

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

#### Rule multi-triggering{% #rule-multi-triggering-rt-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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Decrease severity for non-production environments{% #decrease-severity-rt-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`.

#### Enable optional group by{% #enable-group-by-rt-anomaly %}

Toggle the **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.

#### Group signals{% #group-signals-rt-anomaly %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Content anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Content anomaly)

{% image
   source="https://docs.dd-static.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`.Important alert (level: info): 
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 **And notify** section, click **Add Recipient** to optionally configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to avoid manual edits to notification preferences for individual detection rules.

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

#### Content anomaly detection{% #content-anomaly-rt-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.md#anomaly-detection-parameters) for more information.

#### Rule multi-triggering behavior{% #rule-multi-triggering-rt-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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Decrease severity for non-production environments{% #decrease-severity-rt-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`.

#### Enable optional group by{% #enable-group-by-rt-content-anomaly %}

Toggle the **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.

#### Group signals{% #group-signals-rt-content-anomaly %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Impossible travel)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Impossible travel)

{% image
   source="https://docs.dd-static.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 **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

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

#### Rule multi-triggering{% #rule-multi-triggering-rt-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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Decrease severity for non-production environments{% #decrease-severity-rt-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`.

#### Enable optional group by{% #enable-group-by-rt-impossible-travel %}

Toggle the **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.

#### Group signals{% #group-signals-rt-impossible-travel %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Third party)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Third party)

{% image
   source="https://docs.dd-static.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 **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) 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-6 %}

#### Decrease severity for non-production environments{% #decrease-severity-rt-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`.

#### Enable optional group by{% #enable-group-by-rt-third-party %}

Toggle the **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.

#### Group signals{% #group-signals-rt-third-party %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Real-time rule) and (Detection method is Sequence)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) and (Detection method is Sequence)

#### Rule multi-triggering{% #rule-multi-triggering-rt-sequence %}

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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Decrease severity for non-production environments{% #decrease-severity-rt-sequence %}

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

#### Enable optional group by{% #enable-group-by-rt-sequence %}

Toggle the **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.

#### Group signals{% #group-signals-rt-sequence %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Threshold)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Threshold)

{% image
   source="https://docs.dd-static.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.Important alert (level: info): 
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`.Important alert (level: info): 
The query label must precede the operator. For example, `a > 3` is allowed; `3 < a` is not allowed.
1. (Optional) In the **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to avoid manual edits to notification preferences for individual detection rules.

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

#### Rule multi-triggering{% #rule-multi-triggering-scheduled-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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Decrease severity for non-production environments{% #decrease-severity-scheduled-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`.

#### Enable optional group by{% #enable-group-by-scheduled-threshold %}

Toggle the **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.

#### Group signals{% #group-signals-scheduled-threshold %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is New value)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is New value)

{% image
   source="https://docs.dd-static.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 **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

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

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

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

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

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

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

Toggle the **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.

#### Group signals{% #group-signals-scheduled-new-value %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Anomaly)

{% image
   source="https://docs.dd-static.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 **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

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

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

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

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

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

Toggle the **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.

#### Group signals{% #group-signals-scheduled-anomaly %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Content anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Content anomaly)

{% image
   source="https://docs.dd-static.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`.Important alert (level: info): 
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 **And notify** section, click **Add Recipient** to optionally configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to avoid manual edits to notification preferences for individual detection rules.

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

#### 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.md#anomaly-detection-parameters) for more information.

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

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

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

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

Toggle the **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.

#### Group signals{% #group-signals-scheduled-content-anomaly %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Impossible travel)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Impossible travel)

{% image
   source="https://docs.dd-static.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 **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to manage notifications automatically, avoiding manual edits for each detection rule.

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

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

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

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

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

Toggle the **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.

#### Group signals{% #group-signals-scheduled-impossible-travel %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Scheduled rule) and (Detection method is Third party)" %}
This section only applies to users who meet the following criteria: (Rule type is Scheduled rule) and (Detection method is Third party)

{% image
   source="https://docs.dd-static.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 **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) 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-12 %}

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

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

Toggle the **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.

#### Group signals{% #group-signals-scheduled-third-party %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Threshold)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Threshold)

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/threshold_historical_condition.96e975107a46b8695ee7e475cd9be018.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.Important alert (level: info): 
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`.Important alert (level: info): 
The query label must precede the operator. For example, `a > 3` is allowed; `3 < a` is not allowed.
1. (Optional) In the **And notify** section, click **Add Recipient** to configure [notification targets](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels).
   - You can also create [notification rules](https://docs.datadoghq.com/security/notifications/rules.md) to avoid manual edits to notification preferences for individual detection rules.

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

#### Job multi-triggering{% #job-multi-triggering-threshold %}

In the **Job multi-triggering behavior** section, configure how often to keep updating the same signal when new values are detected within a specified time frame. For example, the same signal updates when any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` defines a sliding period in which at least one case evaluates as true and assesses 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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Enable optional group by{% #enable-group-by-historical-threshold %}

Toggle the **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.

#### Group signals{% #group-signals-historical-threshold %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is New value)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is New value)

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

#### Forget value{% #forget-value-historical-new-value %}

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

#### Job multi-triggering behavior{% #job-multi-triggering-historical-new-value %}

In the **Job multi-triggering behavior** section, configure how often to keep updating the same signal when new values are detected within a specified time frame. For example, the same signal updates when any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` defines a sliding period in which at least one case evaluates as true and assesses 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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Enable optional group by{% #enable-group-by-historical-new-value %}

Toggle the **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.

#### Group signals{% #group-signals-historical-new-value %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Anomaly)

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

#### Job multi-triggering{% #job-multi-triggering-historical-anomaly %}

In the **Job multi-triggering behavior** section, configure how often to keep updating the same signal when new values are detected within a specified time frame. For example, the same signal updates when any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` defines a sliding period in which at least one case evaluates as true and assesses 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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Enable optional group by{% #enable-group-by-historical-anomaly %}

Toggle the **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.

#### Group signals{% #group-signals-historical-anomaly %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.

#### Bucket duration{% #bucket-duration %}

In the **Bucket Duration** dropdown, select a duration over which to measure percentiles.

#### Learning duration{% #learning-duration %}

In the **Learning Duration** dropdown, select an amount of time for the rule to learn new values.

#### Learning period alerts{% #learning-period-alerts %}

In the **Learning Period Alerts** dropdown, choose whether you want Cloud SIEM to send alerts during the learning period.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Content anomaly)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Content anomaly)

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/content_anomaly_historical_condition.077c309ecc300edf8b9123d0340551a1.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 **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`.Important alert (level: info): 
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.

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

#### Content anomaly detection{% #content-anomaly-historical-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.md#anomaly-detection-parameters) for more information.

#### Job multi-triggering behavior{% #job-multi-triggering-historical-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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Enable optional group by{% #enable-group-by-historical-content-anomaly %}

Toggle the **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.

#### Group signals{% #group-signals-historical-content-anomaly %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Impossible travel)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Impossible travel)

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

#### Job multi-triggering{% #job-multi-triggering-impossible-travel %}

In the **Job multi-triggering behavior** section, configure how often to keep updating the same signal when new values are detected within a specified time frame. For example, the same signal updates when any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` defines a sliding period in which at least one case evaluates as true and assesses 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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

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

Toggle the **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.

#### Group signals{% #group-signals-impossible-travel %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Third party)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Third party)

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/set_condition_root_query.93eb4c01b6f336e0e14c9a6c33194010.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 **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.

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

#### Enable optional group by{% #enable-group-by-historical-third-party %}

Toggle the **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.

#### Group signals{% #group-signals-historical-third-party %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section
   displayed-if="(Rule type is Historical job) and (Detection method is Sequence)" %}
This section only applies to users who meet the following criteria: (Rule type is Historical job) and (Detection method is Sequence)

#### Rule multi-triggering{% #rule-multi-triggering-historical-sequence %}

In the **Job multi-triggering behavior** section, configure how often to keep updating the same signal when new values are detected within a specified time frame. For example, the same signal updates when any new value is detected within 1 hour, for a maximum duration of 24 hours.

- An `evaluation window` defines a sliding period in which at least one case evaluates as true and assesses 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.

{% alert level="info" %}
The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
{% /alert %}

#### Enable optional group by{% #enable-group-by-historical-sequence %}

Toggle the **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.

#### Group signals{% #group-signals-historical-sequence %}

Toggle **Group signals** if you want to reduce the number of signals generated. Then, select one or more groups for which you want to generate one security signal each.
{% /section %}

{% section displayed-if="Rule type is Scheduled rule" %}
This section only applies to users who meet the following criteria: Rule type is Scheduled rule

## 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://docs.dd-static.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://docs.dd-static.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 for more advanced scheduling use cases.

For example, if the RRULE is:

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

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

{% alert level="info" %}

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

{% /alert %}

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.
{% /section %}

{% section displayed-if="Rule type is Historical job" %}
This section only applies to users who meet the following criteria: Rule type is Historical job

## Notify when job is complete{% #notify-when-job-is-complete %}

(Optional) Click **Add Recipient** to send notifications upon the completion of job analysis. See [Notification channels](https://docs.datadoghq.com/security_platform/notifications.md#notification-channels) for more information.
{% /section %}

## 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.md) 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.md#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.md) 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`.Important alert (level: info): 
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`.

{% section
   displayed-if="(Rule type is Real-time rule) or (Rule type is Scheduled rule)" %}
This section only applies to users who meet the following criteria: (Rule type is Real-time rule) or (Rule type is Scheduled rule)

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

(Optional) Create a suppression or add the rule to an existing suppression to prevent a signal from being 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**.Important alert (level: info): 
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.
{% /section %}



{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/threshold_20250310.5ad2188a658fd5fb9c591f4570f334e3.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/threshold_20250310.5ad2188a658fd5fb9c591f4570f334e3.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/new_value_20250310.1481920276a722442fd96535404612d3.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/new_value_20250310.1481920276a722442fd96535404612d3.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/anomaly_query.19923a9476fb314fd203d59d7ea8a3fb.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/anomaly_query.19923a9476fb314fd203d59d7ea8a3fb.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/content_anomaly_query.dfd62c07fd232437cb885823e91eb6e4.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/content_anomaly_query.dfd62c07fd232437cb885823e91eb6e4.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/impossible_travel_query.764df6c2228f9605ccbeb97d45bf64f7.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/impossible_travel_query.764df6c2228f9605ccbeb97d45bf64f7.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/third_party_query.ef079282a8c45974ca85c18334547cf8.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/third_party_query.ef079282a8c45974ca85c18334547cf8.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sequence/sequence_queries.45e05b16842f0b49425697f5db45de45.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sequence/sequence_queries.45e05b16842f0b49425697f5db45de45.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sql-ocsf-query-example.57acebbe6b89363bb6b680e120110267.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/sql-ocsf-query-example.57acebbe6b89363bb6b680e120110267.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/condition_simple_then.f6b444aa6c435356bc58e5f73180dd8b.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/condition_simple_then.f6b444aa6c435356bc58e5f73180dd8b.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/severity_notification.e8bbde3d25eac5442ab806986df2c96f.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/severity_notification.e8bbde3d25eac5442ab806986df2c96f.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/anomaly_notification.b3c96ac2be10c2ecc254ae1a65ba7ed9.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/anomaly_notification.b3c96ac2be10c2ecc254ae1a65ba7ed9.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/condition_content_anomaly.0c9944113fa88417e4fdb2425c4210da.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/condition_content_anomaly.0c9944113fa88417e4fdb2425c4210da.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/condition_else.b7196e7931f3562be1d01fc5eadb83be.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/condition_else.b7196e7931f3562be1d01fc5eadb83be.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/threshold_historical_condition.96e975107a46b8695ee7e475cd9be018.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/threshold_historical_condition.96e975107a46b8695ee7e475cd9be018.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/content_anomaly_historical_condition.077c309ecc300edf8b9123d0340551a1.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/content_anomaly_historical_condition.077c309ecc300edf8b9123d0340551a1.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/set_condition_root_query.93eb4c01b6f336e0e14c9a6c33194010.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/set_condition_root_query.93eb4c01b6f336e0e14c9a6c33194010.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/custom_schedule.92463bc6d364247473acfc84056854fd.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/custom_schedule.92463bc6d364247473acfc84056854fd.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}

{% image
   source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/rrule_example.521c960776b9de3f50ebb1b19ceb2fd5.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/rrule_example.521c960776b9de3f50ebb1b19ceb2fd5.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="" /%}