--- title: No-data handling description: Learn how no-data handling controls alert behavior when queries return no results, and how to select the correct no-data strategy for metric and log alerts. url: https://coralogix.com/docs/user-guides/alerting/no-data/ product: alerts feature: Alert Definitions feature_id: alert-definitions feature_identifier: alerts/alert-definitions last_updated: '2026-10-23' --- # No data state Decide what an alert does when its query returns no results and the system cannot evaluate the condition. Configure no-data handling when you create or edit a metric or log alert. No-data itself is not a directly notifiable state. You receive notifications only when an alert transitions into a notifiable state, such as **OK** or **alerting**, based on the configured no-data behavior. ## How no-data handling works No-data handling describes how an alert behaves when its query returns no results and the system cannot evaluate the alert condition. When you evaluate an alert: * If the query returns data, the alert evaluates normally. * If the query stops returning results for a series it already observed, the system applies the configured no-data behavior. No-data handling affects alert evaluation and state transitions, not notification delivery. The selected behavior determines which state the alert enters when data is missing. Notifications follow from that resulting state. The same no-data options apply across metric and log alerts. However, the UI might present these options in different places depending on the alert type and how the alert evaluates data. ## What counts as missing data **Missing data behavior** applies when a series the alert already observed stops returning results for the whole timeframe. Whether an empty window counts as a missing series depends on whether the alert groups its results. ### Alerts with Group by The alert evaluates each label permutation on its own. When a permutation that was reporting returns nothing, that permutation is missing data, and the alert applies the behavior you selected. Under **Set alerting** the alert fires for that permutation and holds the alerting state until data returns. ### Alerts without Group by The alert evaluates one overall count. While logs keep arriving for the application, subsystem, and filters the query covers, an empty window evaluates as a count of zero rather than a missing series. The alert compares zero against the threshold like any other value, so the missing data behavior has no effect. A condition such as more than three logs in 10 minutes therefore holds **OK** through a quiet window, because zero sits below three. The same arithmetic is why a condition such as fewer than one log in two hours fires on a quiet window. Note Selecting **Set alerting** on an ungrouped alert leaves its behavior unchanged. Add a **Group by** field if you want the alert to react to a series that goes silent. ### Reading the threshold on the alert graph The alert graph draws the threshold you configured, and the state band below it reflects the state the evaluator computed. On an ungrouped alert a quiet window shows as **OK** because the count of zero genuinely met no condition, whichever missing data behavior you selected. ### Which behavior suits an error threshold alert An alert that counts errors sits on a query where zero is the healthy value. Select **Set OK** on these alerts. * On an ungrouped alert, **Set alerting** changes nothing, so it reads as coverage you do not have. * On a grouped alert, **Set alerting** fires as soon as a permutation stops producing errors, which is the opposite of what an error count should report. Reserve **Set alerting** for queries where a steady signal is the healthy value, such as a heartbeat log, a throughput counter, or an infrastructure metric. ## Where to configure no-data handling Configure no-data handling as part of an alert definition. The alert’s **Advanced settings** contain the no-data options. These settings define how the alert behaves **when data is missing**, rather than how it evaluates thresholds or usual values. No-data handling applies to alert types that rely on query results to determine their state, including: * Metric alerts with threshold conditions * Metric alerts that compare values against a usual or expected range * Log alerts with threshold conditions, if the query has a group-by field * Log alerts that evaluate logs against usual behavior, if the query has a group-by field If an alert relies on query results for evaluation, it supports no-data handling. For log alerts, the group-by requirement below applies on top of that. important A log alert needs at least one group-by field for no-data handling to take effect. A log alert with no group-by field never enters the no-data flow. An empty result is read as a count of zero matching logs and evaluated like any other result, so a log threshold alert compares that zero against its threshold. The no-data options stay selectable in the editor, so nothing warns you and the alert saves normally; the setting is simply not applied. If you need a log alert to react to missing data, add a group-by field to its query. ### Select a no-data behavior When you configure an alert, select how it must behave when no data is available. Each option represents a different assumption about what missing data means for your system. [![no data behaviour](/docs/assets/images/no-data-797184a6d78e5582c419dabc8ac082b0.webp)](https://coralogix.com/docs/assets/images/no-data-797184a6d78e5582c419dabc8ac082b0.webp) The following sections explain each option in detail, including when to use it and what happens after you select it. * Set OK * Set alerting * Keep last state * Set no data state Select **Set OK** when you expect missing data and it does not indicate a problem. This option suits workloads that are intentionally silent or emit data only under specific conditions. **Typical scenarios** * Batch jobs that emit metrics only while running * Services that intentionally scale to zero * Periodic tasks that do not produce continuous telemetry **Alert behavior** * When no data is available, the alert transitions to the **OK** state. * The alert does not indicate an issue while data is missing. **Things to consider** * If telemetry stops unexpectedly, this option can hide real issues. * Select this option only when you expect and understand periods with no data. Select **Set alerting** when missing data likely signals a problem. **Typical scenarios** * Infrastructure metrics (CPU, memory, disk) * Core services that must always be running * Critical pipelines where missing data likely indicates a failure **Alert behavior** * When no data is available, the alert transitions to the **alerting** state. * The system treats missing data the same as a breached alert condition. **Things to consider** * This option can generate alerts during telemetry outages. * Select it when data availability matters as much as metric values. Select **Keep last state** when short or intermittent gaps in data are routine. This option prevents alert state changes caused by brief interruptions in data ingestion. **Typical scenarios** * Temporary network issues * Short ingestion delays * Metrics scraped at irregular intervals **Alert behavior** * When no data is available, the alert remains in its previous state. * The alert resumes normal evaluation when data returns. **Things to consider** * Long gaps leave the alert in whatever state it last held. * This option prioritizes stability over immediate visibility into missing data. Select **Set no data state** when you want to track missing data as its own condition. This option is ideal when missing data is neither OK nor alerting, but still important to observe and act on. **Typical scenarios** * Telemetry and platform monitoring * Detecting broken exporters or agents * Identifying misconfigured queries or missing labels after deployments **Alert behavior** * When no data is available, the alert enters a **no data** state. * The no-data state is visible in the UI and alert timelines. **Things to consider** * This option provides the clearest visibility into data availability issues. * It helps you distinguish between a system that is unhealthy and a system that is silent. ### Important considerations * For log alerts, check that the query has at least one group-by field. Without one, the no-data behavior you select is not applied. * Review no-data behavior whenever you change queries, labels, scaling behavior, or ingestion pipelines. * Select Set OK only when you expect and accept silent periods. * Use Set no data state to obtain the clearest visibility into data availability issues. ### What happens when data returns When data returns, the alert resumes normal evaluation: * If you selected Set no data state, the alert exits the no-data condition. * The system evaluates new data using the configured lookback and evaluation windows. * The alert transitions to OK or alerting based on the new results. You don’t need to take manual action. ### Example timeline 1. You evaluate the alert and it enters alerting. 2. The query stops returning results; the alert follows your configured no-data behavior. 3. Data resumes and the alert reevaluates. 4. The alert moves to OK if the condition no longer applies, or stays alerting if it still applies. ### How evaluation windows apply When data returns, the system evaluates only new data using the configured lookback and evaluation windows. The system does not replay missing data. This approach ensures alert decisions reflect current system behavior rather than historical gaps. ### Avoiding alert flapping Short data interruptions do not immediately trigger repeated state changes. Select **Keep last state** or **Set no data state** to reduce unnecessary transitions during brief interruptions. ### Visibility of no-data states When you select **Set no data state**, the alert enters a distinct no-data state that appears in alert timelines and status views. This distinction helps you tell the difference between: * Alerts that fire when conditions meet thresholds * Alerts that the system cannot evaluate because data is missing ### No-data settings and notifications No-data settings affect alert evaluation and state transitions only. They do not automatically trigger notifications. The system sends notifications only when an alert transitions into a notifiable state according to your routing and notification configuration. ### When to review no-data settings Review no-data settings regularly to ensure they still match how your systems operate. Revisit no-data settings when: * You add, remove, or change labels in metric or log queries * You change deployment or scaling behavior * Alerts remain unexpectedly quiet * Alert timelines show frequent transitions into and out of no-data states Clear no-data configuration keeps alert behavior predictable, reduces confusion during incidents, and simplifies troubleshooting when data goes missing. Think of no-data handling as deciding how the alert evaluates missing data, not when the system sends notifications. ## Related resources [Configure alert definition](https://coralogix.com/docs/user-guides/alerting/configuring-alert-definition.md)[Introduction to alerts](https://coralogix.com/docs/user-guides/alerting/introduction-to-alerts.md)[Notification Center](https://coralogix.com/docs/user-guides/notification-center/introduction.md) ## Next steps Eliminate unnecessary alerts during maintenance or off-hours with [Suppression Rules](https://coralogix.com/docs/user-guides/alerting/alert-suppression-rules.md).