Cx Alerts

Alert Management Skill

Use this skill to list, inspect, create, delete, enable, and disable Coralogix alert definitions using the cx alerts CLI commands.

CLI Commands

Output format: append -o json or -o toon to list, get, and create commands for machine-readable output.

Multi-profile: use -p <profile> (repeatable) to target multiple profiles simultaneously.

Alert Types Reference

Coralogix supports 12 alert types:

Priority Levels

Always ask the user what priority to use when creating alerts:

Create Workflow

1. Ask the user what they want to alert on (logs, metrics, traces)
2. Ask for priority (P1–P5)
3. Build the JSON payload with alertDefProperties - use the API wire format (see references/alert-schemas.md for all enum values)
4. Tip: use cx alerts get <existing-id> -o json to get a working template, modify it, and pipe into create
5. Create using: echo '<json>' | cx alerts create or cx alerts create --from-file alert.json
6. Verify with cx alerts list --name "<alert name>"

Important structural note: The type field is a string enum (e.g. "ALERT_DEF_TYPE_LOGS_THRESHOLD"), and the alert type config (e.g. "logsThreshold": {...}) is a sibling field at the same level - NOT nested inside type.

Example: Logs Threshold Alert

{  "alertDefProperties": {    "name": "High Error Rate",    "description": "Alert when error logs exceed threshold",    "priority": "ALERT_DEF_PRIORITY_P2",    "type": "ALERT_DEF_TYPE_LOGS_THRESHOLD",    "enabled": true,    "logsThreshold": {      "logsFilter": {        "simpleFilter": {          "luceneQuery": "severity:ERROR",          "labelFilters": {            "applicationName": [              { "operation": "LOG_FILTER_OPERATION_TYPE_IS_OR_UNSPECIFIED", "value": "my-app" }            ]          }        }      },      "rules": [{        "condition": {          "conditionType": "LOGS_THRESHOLD_CONDITION_TYPE_MORE_THAN_OR_UNSPECIFIED",          "threshold": 100,          "timeWindow": {            "logsTimeWindowSpecificValue": "LOGS_TIME_WINDOW_VALUE_MINUTES_5_OR_UNSPECIFIED"          }        }      }]    }  }}

Example: Metric Threshold Alert

{  "alertDefProperties": {    "name": "CPU Usage Critical",    "priority": "ALERT_DEF_PRIORITY_P1",    "type": "ALERT_DEF_TYPE_METRIC_THRESHOLD",    "enabled": true,    "metricThreshold": {      "metricFilter": { "promql": "avg(cpu_usage_percent)" },      "rules": [{        "condition": {          "conditionType": "METRIC_THRESHOLD_CONDITION_TYPE_MORE_THAN_OR_UNSPECIFIED",          "threshold": 90,          "ofTheLast": { "dynamicDuration": "5m" },          "forOverPct": 100        }      }]    }  }}

Example: Logs Immediate Alert

{  "alertDefProperties": {    "name": "OOM Killer Detected",    "description": "Alert immediately when OOM killer runs",    "priority": "ALERT_DEF_PRIORITY_P1",    "type": "ALERT_DEF_TYPE_LOGS_IMMEDIATE_OR_UNSPECIFIED",    "enabled": true,    "logsImmediate": {      "logsFilter": {        "simpleFilter": {          "luceneQuery": "\"Out of memory\" OR \"OOM\"",          "labelFilters": {}        }      }    }  }}

Investigation Workflow

Find firing alerts

# List all alerts and look for ALERTING statuscx alerts list -o json | jq '.[] | select(.status == "ALERTING")'
# Filter by namecx alerts list --name "error"

Inspect a specific alert

cx alerts get <alert-id>cx alerts get <alert-id> -o json

Disable a noisy alert (temporary mute)

cx alerts disable <alert-id># Later, re-enable:cx alerts enable <alert-id>

Suppression Rules

Manage alert suppression rules that mute alerts during maintenance windows or known noisy periods.

# List suppression rulescx alerts suppression-rules list -o json
# Create from templatecx alerts suppression-rules get <existing-id> -o json > suppression-rule.json# Edit suppression-rule.jsoncx alerts suppression-rules create --from-file suppression-rule.json

Key Principles

• Always ask for priority (P1–P5) when creating alerts - never assume
• Use --name filter for large accounts with many alerts
• Use -o json with jq for filtering and transformation
• Use --from-file - to pipe JSON from stdin when constructing alerts programmatically
• Verify after create - always list or get the alert after creation to confirm
• Disable, don't delete - prefer disabling alerts over deletion for auditability
• Link to a specific alert - cx alerts list prints only one "View in Coralogix" link, to the alerts overview page, not a per-alert link. To link a user to one specific alert, build <base>/alerts/<alert_id>, where <base> is the console URL already seen in a `View in Coralogix: <base>/...` line printed by any `cx alerts` command this session - never fabricate `<base>` yourself.

Additional Resources

Reference Files

• references/alert-schemas.md [blocked] - Complete JSON schema reference for all 12 alert types: field names, enum values (condition types, time windows, filter operations), common sub-objects (logs filter, tracing filter, notification groups, activity schedules), and important gotchas
• references/dataprime-reference.md [blocked] - DataPrime query language reference for log-based and span-based alert conditions (filter syntax, operators, severity values)
• references/logs-querying.md [blocked] - Log data model, field discovery, and query patterns for building log alert conditions
• references/promql-guidelines.md [blocked] - PromQL reference for metric-based alert conditions (counters, gauges, histograms, threshold patterns)
• references/spans-querying.md [blocked] - Span data model, duration units, and query patterns for building tracing alert conditions

Related Skills

• cx-cases - triage the cases that group alert events into investigations
• cx-slos - the SLO definitions whose error-budget burn raises alerts
• cx-observability-setup - setting up notification routing and webhook integrations for alerts
• cx-telemetry-querying - investigate the telemetry behind a firing alert