As part of Coralogix [Alerting](https://coralogix.com/docs/user-guides/alerting/introduction-to-alerts/index.md), metric alerts monitor metric behavior and trigger notifications when predefined thresholds are met or exceeded. These alerts help you maintain system performance, reliability, and security.

Metric alerts evaluate specific metrics in your Coralogix dashboard and notify you when conditions cross the thresholds you configure. They monitor critical performance indicators, such as CPU utilization, response times, error rates, and resource usage in cloud environments, and provide early warning when values deviate from expected behavior.

You can create PromQL-based metric alerts for standard metric sources such as [Prometheus](https://coralogix.com/https/coralogixcom/docs/integrations/metrics/prometheus/) and [CloudWatch](https://coralogix.com/docs/integrations/aws/aws-cloudwatch/aws-cloudwatch-metrics-processing/index.md) or for metrics extracted from logs through [Events2Metrics](https://coralogix.com/docs/user-guides/monitoring-and-insights/events2metrics/index.md)

## What do you need

- Ingest metrics into Coralogix.
- Define a PromQL query that returns the values you want to evaluate.

## Create an alert

1. Go to **Alerts**, then **Alert management**.
1. Select **Create alert**.
1. In **Alert type**, select **Metric**.

## Add alert details

In the **Details** section:

- Enter the **alert name**.
- Enter the **alert description**, which appears in alert notifications.
- Add **labels**, or nest labels using `key:value`.
- Select **Set as security alert** to add the `alert_type:security` label so you can filter these alerts in the **Incidents** page.

## Define the PromQL query

In the **Query** section:

- Enter the expression in **Search query**.
- Select **PromQL Documentation** if you need reference material.

Note

- The system displays auto-complete suggestions as you type.
- Aggregate values by application, subsystem, instance, or any metric label.
- Add labels to narrow a metric, for example:

```text
application_error_count{area="x"}
```

- Use `by()` to aggregate and control notification grouping, for example:

```text
sum by(instance) (node_filesystem_size_bytes)
```

## Configure conditions

Use the **Conditions** section to define when the metric alert triggers. The system evaluates each condition rule in priority order and triggers the alert when the highest-priority rule evaluates to true.

### Select the alert condition type

In **Alert when**, select one of the following operators:

- **Less than threshold**
- **Less than or equals threshold**
- **More than threshold**
- **More than or equals threshold**
- **More than usual** (dynamic alert)
- **Less than usual** (dynamic alert)

Dynamic alerts use behavior-based baselines. All other operators evaluate static thresholds.

## Set condition rules

Each rule follows this structure:

When the query returns:

- `<operator>`
- `<number>`
- `for at least` / `at least once in` / `for over`
- `<time>` `<unit>` trigger a `<severity>` alert.

Select **+ Add condition rule** to add more evaluation paths. The system evaluates rules by priority.

## Threshold evaluation modes

Metric threshold alerts use three evaluation modes that define how long the threshold must remain true in the selected timeframe.

- **for at least**: The threshold must remain true for the entire timeframe with no interruptions. **Example**: If you configure `more than 1 for at least 5 minutes`, the metric must stay above 1 continuously for all 5 minutes.
- **at least once in**: The threshold must occur at least one time in the timeframe. **Example**: If you configure `at least once in 10 minutes`, the alert triggers if the metric crosses the threshold once in that 10-minute window.
- **for over x%**: The threshold must hold for more than a percentage of the timeframe. **Example**: If you configure `for over 10% of 10 minutes`, the metric must exceed the threshold for more than 1 minute.

Additional rules:

- **0%**: the alert triggers if the threshold is crossed once.
- **100%**: every value in the timeframe must meet the threshold.

## Percentage requirements and missing values

Percentage requirements define how many data points must exist before the alert can trigger reliably.

- **0%**: any breach can trigger the alert.
- **100%**: every data point must exist and meet the threshold.
- When data is missing, the system calculates percentages from existing points unless you replace missing values with 0.

**Why this matters**

If you query 10 minutes of data and only 6 data points exist, those 6 points represent 100% of the timeframe unless the system replaces missing values with 0. This behavior can cause false triggers.

## Replace missing values with 0

Enable **Replace missing values with 0** to treat missing data points as 0. When enabled, the system hides percentage controls because 0-values guarantee full data coverage.

## Advanced settings

Expand **Advanced settings** to modify evaluation behavior.

### Delay alert evaluation

Delay evaluation by a set number of seconds to avoid triggering from ingestion delays or transient spikes.

## Undetected values (Less than operators only)

Note

Undetected values work only in alert v2.

The **Undetected values** section appears only when you use a **Less than** operator. Undetected values occur when a metric label permutation stops sending data. Without safeguards, these gaps can trigger repeated alerts.

Use the controls in this section to manage how the alert handles missing metric series:

- *Enable triggering on undetected values* to turn this behavior on or off.
- *Auto retire* to retire undetected values after a selected period (None, Never, 24h, 12h, 6h).
- Manual retirement while reviewing triggered alerts.

## Missing data behavior

Note

Missing data behavior works only in alert v3.

Metric alerts also define how Coralogix should behave when a query returns [no data](https://coralogix.com/docs/user-guides/alerting/no-data/index.md).

[No data](https://coralogix.com/docs/user-guides/alerting/no-data/index.md) can occur when a metric stops being reported, a resource is removed, or ingestion is delayed.

In the **Advanced settings** section, configure **When there is no data**.

| Option                | Behavior                                                    |
| --------------------- | ----------------------------------------------------------- |
| **Set OK**            | The alert is resolved when no data is received.             |
| **Set alerting**      | The alert is triggered when the metric stops reporting.     |
| **Keep last state**   | The alert remains in its previous state until data resumes. |
| **Set no data state** | The alert enters a dedicated No Data state.                 |

### How to select

| Goal                                                  | Recommended option    |
| ----------------------------------------------------- | --------------------- |
| Detect stopped services or missing components         | **Set alerting**      |
| Ignore expected gaps (ephemeral jobs, scaling events) | **Set OK**            |
| Avoid state changes during brief ingestion delays     | **Keep last state**   |
| Distinguish no data from healthy or unhealthy         | **Set no data state** |

### Auto-retire

Enable **Auto retire** to stop tracking missing series after a defined period (for example, 24 hours). This prevents repeated evaluations for resources that no longer exist.

## Preview the alert

For **metric-based alerts**, use the **Query Builder**. Builder mode lets you construct metric queries by selecting metrics, filters, and functions without writing raw PromQL. Switch to **Query** mode at any time to view or edit the generated query directly.

As you build the query, a result preview appears automatically. The preview:

- Evaluates the full alert definition (query + condition)
- Uses the last 24 hours of historical data
- Shows whether the alert would have triggered
- Highlights triggered timeframes
- Reflects how long the condition would have remained triggered

The preview evaluates the complete alert logic, including duration requirements. For example:

- If the condition is **More than 1 at least once in 30 minutes**, each threshold crossing is highlighted
- If the condition is **More than 1 for over 30 minutes**, only continuous threshold breaches lasting 30 minutes are highlighted

If the metric briefly crosses the threshold but does not satisfy the duration requirement, it does not appear as triggered.

When the query returns more than 20 series (for example, when grouping by multiple labels), the preview displays a sample of up to 20 permutations. Ordering is not guaranteed and may change based on query parameters. If you need to evaluate a specific permutation, refine the query with additional filters or narrower grouping.

Note

Preview results may differ from live evaluation due to metric ingestion delays, over-time aggregations, and complex expressions. Treat the preview as directionally accurate guidance.

## Configure notifications

In the **Notifications** section:

- **Notify every**: Set the minimum time between notifications while the alert remains active. The system suppresses additional notifications until the interval passes.
- **Notify when resolved**: Send a notification when the alert condition clears.
- **Grouped notifications**: When the query returns multiple label combinations, select one of the following:
- **Trigger a single alert when at least one combination meets the condition**: Send one aggregated incident with all matching combinations.
- **Trigger a separate alert for each combination that meets the condition**: Select label keys to split notifications. The system sends one incident per combination.

Note

- Enter Group By keys as free text.

- The system evaluates up to 1,000 permutations and tracks only the first 1,000.

- **Webhooks**: Select **+ Add webhook** to send notifications to Slack, PagerDuty, or custom endpoints.

## Phantom mode

Toggle **Enable Phantom mode** to silence the alert. Phantom alerts do not create incidents or send notifications and work as components inside Flow alerts.

## Schedule (optional)

Use **Schedule** to restrict when the alert can trigger, based on your local time.

## View alert activity

### Incidents page

Use the **Incidents** page to view active and historical alert events. Drill down into an event to review conditions, queries, and metric values. For more information, see [Incidents](https://coralogix.com/docs/user-guides/alerting/incidents/index.md).

### Alert map

Use **Alert map** to view a real-time grid of all alert statuses. Go to **Alerts**, then **Alert map**. For more information, see [Alert Maps](https://coralogix.com/docs/user-guides/alerting/alerts-map/index.md)

## FAQs

- How long does a new alert take to activate?

  Expect each new alert to activate within 15 minutes, usually sooner.

- How does the system define step intervals?

  - Up to 30 minutes → 1-minute steps
  - Up to 12 hours → 5-minute steps
  - Over 12 hours → 10-minute steps

- Why do I see missing values?

  Your data might arrive late, or ingestion might be delayed.

- How do I avoid false triggers from missing values?

  Replace missing values with 0 or require 100% of the timeframe to contain data.

- How do I debug an alert?

  View the metric in Grafana or a Coralogix Custom Dashboard to check data completeness and ingestion timing.

- What if 0 is a valid value?

  Use a PromQL function that ensures the query returns a value instead of null.

## Deprecation notice

Coralogix is deprecating Lucene-based metric alerts and will convert them automatically to PromQL as part of the transition from Logs2Metrics to Events2Metrics.

## Related resources

[Configure alert definition](https://coralogix.com/docs/user-guides/alerting/configuring-alert-definition/) [Metric-based query](https://coralogix.com/docs/user-guides/alerting/metric-based-query/) [Notification Center](https://coralogix.com/docs/user-guides/notification-center/introduction/) [Cases](https://coralogix.com/docs/user-guides/cases/overview/)

## Next steps

Set up latency and service-based alerting for traces in [Tracing alerts](https://coralogix.com/docs/user-guides/alerting/create-an-alert/traces/tracing-alerts/index.md).

## Support

Reach our customer success team 24/7 via the in-app chat or by email at [support@coralogix.com](mailto:support@coralogix.com).
