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 one data source (logs, metrics, traces, or security data) already integrated
• A clear idea of what condition or pattern you want to monitor
• Notification destinations (e.g., Slack, email, webhooks) configured if you want alerts to be routed externally

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

Creating an alert definition

1. Navigate to Alerts > Alert Management > 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 two 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 by entering a search string, selecting applications and subsystems, and optionally filtering by severity:

   • Search Query: Provide a log search string (e.g., object.reason:"NodeNotReady").
   • Applications: Select one or more apps to scope the query.
   • Subsystems: Choose subsystems to further narrow the search.
   • Severities: Select specific log severities.

5. 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:
     Click Advanced Settings, then select Delay alert evaluation and choose a specific time period. This reduces the risk of false positives caused by real-time data fluctuations.

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

   

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

8. Customize notification content:

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

9. Verify before saving:

   • Click 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.