cx-cases

Cases Management Skill

A Case groups related alert events into one investigation unit with a status, priority, category, and assignee. Use this skill to inspect cases and drive them through their lifecycle (active → acknowledged → resolved → closed).

CLI Commands

Case Lifecycle

PENDING_ACTIVATION ──► ACTIVE ◄────────► ACKNOWLEDGED
                         │ ╲                │ ╲
                         │  ╲               │  ╲
                         ▼   ╲              ▼   ╲
                      CLOSED  ╲──► RESOLVED ◄─── (from ACK)
                                       │
                                       ▼
                                    CLOSED  (terminal)

Categories: AVAILABILITY or SECURITY. Priorities: P1 (highest) → P5.

Triage Workflow

1. Inspect — cx cases get <id>. The payload includes groupings,

labels, impactedEntities, kpiBreaches, aiSummary, and both priorityDetails.system (computed) and priorityDetails.override (user-set).

1. Investigate — Pull the underlying telemetry by querying the alert's DataPrime / PromQL to find root cause before acting.

Optionally export the investigation via cx olly or pull the case's impactedEntities / groupings to confirm the impact. See the cx-telemetry-querying skill.

1. Claim — cx cases assign <id> --user you@example.com then

cx cases acknowledge <id>.

1. Record findings — cx cases comment <id> --text "<note>" to leave

investigation notes on the timeline (root cause, links, next steps) as you go. Comments appear as comment events in cx cases events list.

1. Resolve or close — see below.
2. Re-prioritize if impact differs from the computed value —

cx cases set-priority <id> --priority P1 / clear-priority. Only possible while the case is still open; priority cannot be overridden once a case is RESOLVED or CLOSED.

Resolving

Resolution is irreversible (a RESOLVED case can only move to CLOSED), so the CLI requires both a reason and a confirmation:

• Pass --reason "<text>" — a one-line postmortem (root cause, what fixed it,

follow-up) visible to teammates in the timeline. Use --no-reason only when a reason genuinely doesn't apply.

• In agent / non-interactive mode, also pass --yes; without it the command

refuses and must be handed to the user to run interactively.

If uncertain, stay in ACKNOWLEDGED (reversible via unacknowledge) until confident. For non-resolution edits (title, post-hoc postmortem link), use cx cases update.

Bulk Operations

There are no bulk endpoints. To act on many cases, pipe IDs through a loop, e.g. ... | jq -r '.[].id' | xargs -I {} cx cases acknowledge {}.

Key Principles

• Use emails, never user IDs — for assign --user and in all output.
• `resolve` is irreversible and `close` is terminal — confirm before resolving;

for false alarms close from ACTIVE directly.

• Always supply a resolution reason unless --no-reason truly applies.
• `P1`-style shorthand is accepted anywhere a priority/status/category is expected.
• Multi-profile fan-out with -p <profile> (repeatable) for cross-environment triage.
• Link to a specific case — build <base>/cases?id=<case_id>, where

<base> is the console URL already seen in a View in Coralogix: <base>/... line printed by any cx cases command this session — never fabricate <base> yourself.

References

• Case analytics: `references/case-analytics.md`
• Single case investigation: `references/single-case.md`

Related Skills

• `cx-alerts` — the alert definitions behind the events grouped into a case.
• `cx-slos` — the SLO definitions whose breaches drive reliability cases.
• `cx-telemetry-querying` — pivot from a case's impacted entities into logs/spans/metrics.