---
title: No-data handling in Kibana Universal Alerting
description: How to configure the no-data strategy for rules: hold the last known alert state, trigger recovery, or ignore an empty query result.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/configure-no-data-handling
products:
  - Elastic Documentation
  - Kibana
applies_to:
  - Elastic Cloud Serverless: Generally available
  - Elastic Stack: Experimental in 9.5
---

# No-data handling in Kibana Universal Alerting
No-data handling is an optional setting for Kibana Universal Alerting rules that group matches into an alert. It controls what the rule does when it can't tell whether an alert has genuinely recovered or the data just stopped showing up. Setting this correctly prevents false recoveries and misleading `no_data` events when data sources stop reporting. In the rule form, the setting is **No data behavior**.
In YAML, set no-data handling with these settings:
- <applies-to>Elastic Cloud Serverless: Generally available</applies-to> <applies-to>Elastic Stack: Planned</applies-to> The `no_data` object.
- <applies-to>Elastic Stack: Experimental in 9.5</applies-to> The `no_data_strategy` field.


## How no-data handling fits into recovery

<applies-switch>
  <applies-item title="{ serverless: ga, stack: ga 9.6+ }" applies-to="Elastic Cloud Serverless: Generally available, Elastic Stack: Planned">
    When a breached group stops matching, the rule runs a presence query to check whether the group still has data. By default, the presence query is the [base query](/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/configure-rule-query#query-base). To use a different query, set `no_data.query`.
    - **Group still has data**: The group isn't missing, so the rule treats this as a genuine [recovery](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/configure-rule-recovery) rather than a data gap. With **Custom recovery**, the alert recovers when the recovery condition matches. If the group has data but the condition doesn't match, the alert stays open.
    - **Group has no data**: The rule can't tell whether the problem cleared up or the data source stopped reporting. What happens next depends on **No data behavior**.
    This check runs for each group separately. If one host goes quiet while others keep reporting, the rule applies **No data behavior** to the alert for that host.If **No data behavior** is **Do nothing**, the rule skips the presence query. With **Default recovery**, every group that stops matching then recovers.**No data behavior** applies with any recovery option. With **No recovery**, the rule never recovers an alert on its own, but **Recover immediately** can still close an alert when its group has no data.To use **Keep last known status** or **Recover immediately**, the rule needs an alert condition or a no-data query. Without one, a group that stops breaching looks the same as a group that has no data.
  </applies-item>

  <applies-item title="stack: experimental =9.5" applies-to="Elastic Stack: Experimental in 9.5">
    When a breached group stops matching, the rule re-runs the [base query](/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/configure-rule-query#query-base) to confirm the group is actually gone before recovering the alert:
    - **Group still there** - The base query still returns the group, confirming this is a genuine [recovery](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/configure-rule-recovery) rather than a data gap.
    - **Group missing too** - The base query returns nothing for the group either, so the rule can't tell whether the problem actually cleared up or the data source just stopped reporting. What happens next depends on how you've configured `no_data_strategy`.
    The check described above is part of the recovery process, so it only runs when `recovery_strategy` is **Default recovery** or **Custom recovery**.If `recovery_strategy` is **No recovery** instead, alerts stay open until someone closes them manually, the base-query check above doesn't run, and `no_data_strategy` has no effect.
  </applies-item>
</applies-switch>


## No-data strategy options

Choose one of the following options in the **No data behavior** field. Each maps to a strategy value if you're editing YAML directly.
<applies-switch>
  <applies-item title="{ serverless: ga, stack: ga 9.6+ }" applies-to="Elastic Cloud Serverless: Generally available, Elastic Stack: Planned">
    | Option                 | `no_data.strategy` value | Description                                                                                                                                                                            |
    |------------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
    | Keep last known status | `keep_last`              | Hold the last known lifecycle state. An active breach stays active and a recovered alert stays recovered.                                                                              |
    | Recover immediately    | `resolve`                | Close the alert the first time the rule finds no data for the group.                                                                                                                   |
    | Do nothing             | `ignore`                 | Skip the no-data check. With **Default recovery**, a group that stops matching recovers, but the rule doesn't confirm that the data pipeline is actually working. This is the default. |
  </applies-item>

  <applies-item title="stack: experimental =9.5" applies-to="Elastic Stack: Experimental in 9.5">
    | Option                 | `no_data_strategy` value | Description                                                                                                                                          |
    |------------------------|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|
    | Keep last known status | `last_known_status`      | Hold the last known lifecycle state. An active breach stays active and a recovered alert stays recovered.                                            |
    | Recover                | `recover`                | Treat absence as recovery.                                                                                                                           |
    | Do nothing             | `none`                   | Skip the no-data check. An empty result is treated the same as **Recover**, but the rule doesn't confirm that the data pipeline is actually working. |
  </applies-item>
</applies-switch>

<applies-to>Elastic Stack: Experimental in 9.5</applies-to> `no_data_strategy` only triggers when the base query returns **zero rows**. If one host or data source goes quiet but others keep reporting, the query still returns rows for the ones still reporting, so `no_data_strategy` won't trigger. To catch a single silent source in that situation, use the ES|QL pattern in [No-data detection](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/esql-no-data-detection), which turns a silent source into its own alert row.

## When to configure no-data handling

Configure no-data handling when:
- The data source your rule monitors can go silent. Examples include a metrics agent that stops reporting, a pipeline that breaks, or a service that stops generating events.
- A false recovery caused by an empty query result would be more harmful than holding the current alert state.
- Absence of data is itself a signal worth surfacing, such as missing heartbeat events from a critical service.

Leave no-data handling off, or set it to **Do nothing**, when:
- Your data source reliably produces output on every evaluation and a gap in data would indicate a genuine recovery.
- You are still tuning the rule and don't yet know how it behaves when data is absent.


## Examples


### Maintain alert state during a metrics collection outage

Create a rule that monitors infrastructure CPU. Set **No data behavior** to **Keep last known status** so that if the metrics collection agent ever stops sending data, an active CPU breach doesn't auto-recover just because the query returned nothing. Instead, the rule holds the alert in its current state until data resumes.

### Close the alert when a queue empties out

Create a rule that monitors how many jobs are waiting in a queue and opens an alert when the backlog gets too large. To close the alert once the queue is empty and the query has nothing to return, set **No data behavior** to one of these options:
- <applies-to>Elastic Cloud Serverless: Generally available</applies-to> <applies-to>Elastic Stack: Planned</applies-to> **Recover immediately** (`resolve`)
- <applies-to>Elastic Stack: Experimental in 9.5</applies-to> **Recover** (`recover`)


## Related pages

- [Configure a rule](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/configure-a-rule): All configurable rule settings, required and optional.
- [Recovery condition](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/configure-rule-recovery): How no-data handling fits into the recovery process.
- [No-data detection](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/explore-analyze/alerting/esql/rules/esql-no-data-detection): An ES|QL pattern for detecting one specific silent source, rather than an empty base query result.