Configuring an Alert Definition

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.

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.

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

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

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

For log-based alerts, enter a search string, select applications and subsystems, and optionally filter by severity:

• Search query: Enter a log search string, for example object.reason:"NodeNotReady"
• Applications: Select 1 or more applications to scope the query
• Subsystems: Select subsystems to narrow the search
• Severities: Optional: Select specific log severity levels

For metric-based alerts, use the Query Builder. Use the builder mode to 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.

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.

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.

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

   

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

4. Customize notification content:

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

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