In Coralogix, alerts help you detect issues in real time by monitoring logs, metrics, traces, and security data. You can define specific conditions that, when met, trigger notifications to the right teams or systems.

An **alert definition** is a rule that specifies what to monitor, when to trigger an alert, and how to notify. It includes the data source, query filters, condition thresholds, grouping logic, and notification settings. This guide walks you through creating a new alert from start to finish using the Coralogix alerting interface.

### Alert creation workflow

```
flowchart LR
    Details["1. Details"]
    Type["2. Alert type"]
    Query["3. Query"]
    Conditions["4. Conditions"]
    Notifications["5. Notifications"]
    Schedule["6. Schedule"]
    Create["Create alert"]

    Details --> Type --> Query --> Conditions --> Notifications --> Schedule --> Create

    class Details entry
    class Create success
```

## Prerequisites

Before creating an alert, make sure you have:

- Access to the Coralogix platform with permissions to create alerts
- At least 1 data source (logs, metrics, traces, or security data) already integrated
- A clear idea of what condition or pattern you want to monitor
- Notification destinations (for example, Slack, email, webhooks) configured if you want alerts to be routed externally

Understanding what an alert definition is helps you configure meaningful, accurate alerts that avoid noise and false positives.

## Creating an alert definition

1. Go to **Alerts**, then **Alert Management**, and select **New Alert** to access the alert definition screen.

1. Select the alert type that aligns with your monitoring goal:

   | **Alert Type**    | **Description**                                                                                       |
   | ----------------- | ----------------------------------------------------------------------------------------------------- |
   | **Standard**      | Alert based on number of log occurrences. Includes Immediate, Threshold, and Anomaly alerts for logs. |
   | **Ratio**         | Alert based on the ratio between 2 log queries.                                                       |
   | **New Value**     | Alert on a never-before-seen log value.                                                               |
   | **Unique Count**  | Alert based on the unique value count per key in logs.                                                |
   | **Time Relative** | Alert based on the ratio between timeframes.                                                          |
   | **Metric**        | Alert based on arithmetic operations on metrics. Includes Threshold and Anomaly types.                |
   | **Tracing**       | Alert based on tracing latency. Can be Immediate or Threshold-based.                                  |
   | **Flow**          | Alert based on a combination of alerts within a specific timeframe.                                   |
   | **SLO**           | Alert when the error budget is close to exhaustion or is burning too fast.                            |

1. Enter alert details, including name, optional description, labels, and security designation (if applicable):

   - **Alert Name**: Enter a descriptive name.
   - **Alert Description** *(optional)*: Describe what the alert monitors or why it matters.
   - **Labels** *(optional)*: Add key-value pairs to categorize or filter alerts.
   - **Security Alert** *(optional)*: Check if the alert is security-related.

1. Define the query based on the selected alert type.

   Configure the query that determines which data the alert evaluates.

   - **Log-based alerts**: Enter a search query, select applications and subsystems, and optionally filter by severity.
   - **Metric-based alerts**: Use the **Query Builder** to construct metric queries. For detailed instructions, see [Metrics-based query](https://coralogix.com/docs/user-guides/alerting/metric-based-query/index.md).

   **Alert backtest evaluation**: As you build the query, a result preview appears automatically using the last 24 hours of data. The preview evaluates the full alert definition (query and condition), shows when the alert would have triggered, highlights triggered timeframes, and reflects duration requirements.

   For example, **More than 1 at least once in 30 minutes** highlights each threshold crossing, while **More than 1 for over 30 minutes** highlights only continuous breaches lasting 30 minutes. Brief threshold crossings that do not meet duration requirements are not shown 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. 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, or complex expressions.

1. Set alert conditions by defining when the alert should trigger, assigning a priority level (P1–P5), and optionally grouping results. Add additional conditions or configure advanced options as needed:

   - **Define logic**:\
     Trigger when the number of logs within **[Time Window]** is **[greater than / less than] [Value]**, resulting in a **[P1–P5]** alert.

   - **Group By** lets you trigger alerts based on grouped field values. Logs are counted separately for each group, and alerts fire when a group's count crosses the threshold.

     If using two fields like `region` and `pod_name`, logs are grouped by both. Only logs containing both fields are included.

   - **Advanced Settings**:\
     Select **Advanced Settings**, then select **Delay alert evaluation** and select a specific time period. This reduces the risk of false positives caused by real-time data fluctuations.

1. Configure notifications by setting alert frequency, enabling resolution notifications, and optionally enabling **Phantom Mode** to reduce alert noise and serve as a silent trigger within a flow alert sequence.

   - **Phantom Mode**:\
     When enabled, the alert becomes a *Phantom Alert*—it won’t trigger notifications independently. Instead, it can be referenced by **Flow Alerts**. This hides the **Notifications** section from the UI.
   - **Notify Every**:\
     Controls how often notifications are sent if the alert condition remains true (e.g., every 10 minutes).
   - **Notify When Resolved** *(toggle switch)*:\
     When enabled, sends a notification once the condition no longer holds true.

   Note

   - Resolution is **automatic** if the condition evaluates as resolved in the next cycle.

   - **Manual resolution** from the incident screen will **not** send a notification or change alert state.

   - **Webhooks**:

     - Choose delivery methods: Slack, email, generic webhook, etc.
     - Use routing rules to dynamically deliver notifications based on alert fields and metadata.

   > Routing lets you define how notifications are directed to connectors. Destinations can be configured as part of this setup.

1. **Optional schedule**:\
   Restrict alert triggering to specific days or hours (e.g., business hours only).

1. **Customize notification content**:

   - Add JSON fields to include in the notification.
   - Leave blank to send the full log text.

1. **Verify before saving**:

   - Select **Verify** to simulate how the alert would behave using historical data.
   - See how many times the alert would have triggered in the last 24 hours.

   Note

   **Limitations**

   - **Verify** works only with **Frequent Search** alerts.
   - **Not supported** for **Monitoring-tier** alerts (which trigger in real time).
   - This limitation is expected—Monitoring-tier alerts will not return preview results.

Note

New and newly edited alert definitions can take up to **15 minutes** to become active.

Note

**Terraform and API users:** If you create alerts via Terraform or the Alerts API, verify the `notifyOn` field is set correctly. Setting it to `triggered_only` means resolved notifications are never sent to Notification Center. This setting may not be visible in the UI. See [Troubleshoot alerting](https://coralogix.com/docs/user-guides/alerting/troubleshooting/#alert-created-via-api-or-terraform-does-not-behave-as-expected) for details.

Note

**Late-arriving data:** If your metrics arrive with a delay (for example, from batch processing or cross-region replication), consider adding a [custom evaluation delay](https://coralogix.com/docs/user-guides/alerting/custom-evaluation-delay/index.md) to prevent false positives caused by incomplete data at evaluation time.

## Next steps

Learn how to configure metric-based queries in [Metrics-based query](https://coralogix.com/docs/user-guides/alerting/metric-based-query/index.md).

Having issues with your alert? See [Troubleshoot alerting](https://coralogix.com/docs/user-guides/alerting/troubleshooting/index.md).