cx-alerts
coralogix/cx-cli
Manage Coralogix alert definitions—create, list, enable, disable, and configure alerts via CLI.
What is cx-alerts?
This skill provides CLI commands to manage Coralogix alert definitions across 12 alert types (logs, metrics, traces). Use it when you need to create, list, inspect, enable, disable, delete alerts, or manage suppression rules.
- List, inspect, create, delete, enable, and disable alert definitions
- Support 12 alert types: Logs Immediate/Threshold/Anomaly/Ratio/New Value/Unique Count/Time Relative, Metric Threshold/Anomaly, Tracing Immediate/Threshold, and Flow alerts
- Manage alert suppression rules for maintenance windows and noisy periods
- Filter alerts by name and output as JSON or human-readable format
- Target multiple profiles simultaneously with `-p` flag
- Query alert events and event statistics
How to install cx-alerts
npx skills add https://github.com/coralogix/cx-cli --skill cx-alerts- Coralogix account with API access
- cx CLI installed and authenticated with valid profile(s)
How to use cx-alerts
- 1.Run `cx alerts list` to view all alert definitions, optionally filtering by name with `--name <filter>`
- 2.Run `cx alerts get <id>` to inspect a specific alert definition
- 3.To create an alert: determine the alert type (logs/metrics/traces), ask for priority (P1–P5), build JSON payload with `alertDefProperties`, then run `echo '<json>' | cx alerts create` or `cx alerts create --from-file alert.json`
- 4.Run `cx alerts enable <id>` or `cx alerts disable <id>` to toggle alert state
- 5.Run `cx alerts suppression-rules list` to view suppression rules, or create/update/delete with `--from-file` flag
- 6.Append `-o json` to list/get/create commands for machine-readable output; use with `jq` for filtering
Use cases
- Create a threshold alert to trigger when error logs exceed 100 in a 5-minute window
- Set up a metric anomaly alert to detect unusual CPU usage patterns
- Temporarily disable a noisy alert during a known maintenance window
- List all currently firing alerts and investigate their definitions
- Create a suppression rule to mute alerts during scheduled deployments
- DevOps engineers managing Coralogix observability
- On-call engineers investigating firing alerts
- Platform teams configuring alerting policies
- SREs setting up alert suppression for maintenance windows
cx-alerts FAQ
Always ask the user. P1 = critical (pages on-call), P2 = high (within the hour), P3 = medium (business hours), P4 = low (informational), P5 = info only.
Run `cx alerts get <existing-id> -o json` to get a working template, modify the JSON, then pipe it into `cx alerts create` or save to a file and use `--from-file`.
Run `cx alerts disable <alert-id>` to disable it. Re-enable later with `cx alerts enable <alert-id>`. For scheduled maintenance, use suppression rules instead.
Disabling an alert turns it off entirely. Suppression rules mute specific alerts during defined time windows or for specific conditions, then automatically re-enable afterward.
Yes, use the `-p <profile>` flag (repeatable) to run commands across multiple profiles simultaneously.
Full instructions (SKILL.md)
Source of truth, from coralogix/cx-cli.
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
- Ask the user what they want to alert on (logs, metrics, traces)
- Ask for priority (P1–P5)
- Build the JSON payload with
alertDefProperties- use the API wire format (seereferences/alert-schemas.mdfor all enum values) - Tip: use
cx alerts get <existing-id> -o jsonto get a working template, modify it, and pipe into create - Create using:
echo '<json>' | cx alerts createorcx alerts create --from-file alert.json - 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 status
cx alerts list -o json | jq '.[] | select(.status == "ALERTING")'
# Filter by name
cx 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.
| Command | Purpose |
|---|---|
cx alerts suppression-rules list | List all suppression rules |
cx alerts suppression-rules get <id> | Get a suppression rule by ID |
cx alerts suppression-rules create --from-file | Create a suppression rule |
cx alerts suppression-rules update --from-file | Update a suppression rule |
cx alerts suppression-rules delete <id> | Delete a suppression rule |
# List suppression rules
cx alerts suppression-rules list -o json
# Create from template
cx alerts suppression-rules get <existing-id> -o json > suppression-rule.json
# Edit suppression-rule.json
cx alerts suppression-rules create --from-file suppression-rule.json
Key Principles
- Always ask for priority (P1–P5) when creating alerts - never assume
- Use
--namefilter for large accounts with many alerts - Use
-o jsonwithjqfor 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 listprints 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- 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 gotchasreferences/dataprime-reference.md- DataPrime query language reference for log-based and span-based alert conditions (filter syntax, operators, severity values)references/logs-querying.md- Log data model, field discovery, and query patterns for building log alert conditionsreferences/promql-guidelines.md- PromQL reference for metric-based alert conditions (counters, gauges, histograms, threshold patterns)references/spans-querying.md- 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 investigationscx-slos- the SLO definitions whose error-budget burn raises alertscx-observability-setup- setting up notification routing and webhook integrations for alertscx-telemetry-querying- investigate the telemetry behind a firing alert
Related skills
More from coralogix/cx-cli and the wider catalog.

cx-cases
Triage and manage Coralogix Cases—acknowledge, assign, resolve, and track investigation timelines.

cx-cli
Cross-cutting behaviors and update notifications for all cx CLI commands.

cx-cost-optimization
Analyze and optimize Coralogix data costs through usage measurement, TCO policies, and retention management.

cx-dashboards
Build and deploy Coralogix dashboards from service telemetry via cx CLI.

cx-data-pipeline
Configure Coralogix data pipelines: parsing rules, enrichments, Events2Metrics, and recording rules.

cx-incident-management
>