/cx-alerts

name: cx-alerts
description: This skill should be used when the user asks to "manage alerts", "create alert", "list alerts", "delete alert", "check alert status", "enable alert", "disable alert", "investigate firing alerts", "check which alerts are active", "find alerting rules", "set up an alert", "configure alerting", "mute an alert", "silence an alert", "see alert definitions", "check alert priority", or wants to manage Coralogix alert definitions using the cx CLI.
metadata:
  version: "0.1.0"

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

| Command | Purpose | Key flags | |---|---|---| | `cx alerts list` | List all alert definitions | `--name <filter>` | | `cx alerts get <id>` | Get a single alert definition by ID | - | | `cx alerts create` | Create an alert from a JSON definition | `--from-file <path>` (default: stdin) | | `cx alerts delete <id>` | Delete an alert | - | | `cx alerts enable <id>` | Enable an alert | - | | `cx alerts disable <id>` | Disable an alert | - | | `cx alerts events` | List events; use alert-version scoped endpoint when filtering | `--alert-version-id`, `--start`, `--end` | | `cx alerts event-stats` | Get alert event statistics | - | | `cx alerts suppression-rules list` | List suppression rules | - | | `cx alerts suppression-rules get <id>` | Get a suppression rule | - | | `cx alerts suppression-rules create` | Create a suppression rule | `--from-file <path>` | | `cx alerts suppression-rules update` | Update a suppression rule | `--from-file <path>` | | `cx alerts suppression-rules delete <id>` | Delete a suppression rule | - |

**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:

| Type enum | Human name | Description | |---|---|---| | `ALERT_DEF_TYPE_LOGS_IMMEDIATE` | Logs Immediate | Trigger on every matching log entry | | `ALERT_DEF_TYPE_LOGS_THRESHOLD` | Logs Threshold | Trigger when log count exceeds a threshold in a time window | | `ALERT_DEF_TYPE_LOGS_ANOMALY` | Logs Anomaly | ML-based anomaly detection on log volume | | `ALERT_DEF_TYPE_LOGS_RATIO_THRESHOLD` | Logs Ratio Threshold | Trigger on ratio between two log queries | | `ALERT_DEF_TYPE_LOGS_NEW_VALUE` | Logs New Value | Trigger when a new value appears in a field | | `ALERT_DEF_TYPE_LOGS_UNIQUE_COUNT` | Logs Unique Count | Trigger on unique value count threshold | | `ALERT_DEF_TYPE_LOGS_TIME_RELATIVE_THRESHOLD` | Logs Time Relative | Compare current vs past time window | | `ALERT_DEF_TYPE_METRIC_THRESHOLD` | Metric Threshold | Trigger when a PromQL expression crosses a threshold | | `ALERT_DEF_TYPE_METRIC_ANOMALY` | Metric Anomaly | ML-based anomaly detection on metrics | | `ALERT_DEF_TYPE_TRACING_IMMEDIATE` | Tracing Immediate | Trigger on every matching span | | `ALERT_DEF_TYPE_TRACING_THRESHOLD` | Tracing Threshold | Trigger when span count exceeds a threshold | | `ALERT_DEF_TYPE_FLOW` | Flow | Sequence-based alert combining multiple conditions |

Priority Levels

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

| Priority | Use case | |---|---| | P1 | Critical - pages on-call immediately | | P2 | High - needs attention within the hour | | P3 | Medium - investigate during business hours | | P4 | Low - informational, check when convenient | | P5 | Info - logging/tracking only |

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