---name: cx-casesdescription: >metadata: version: 0.1.0---

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

Command	Purpose
cx cases get <id>	Get a single case by ID
cx cases update <id> [--title] [--resolution-reason]	Update mutable fields
cx cases comment <id> --text <text>	Add a comment to the case timeline
cx cases assign <id> --user <email>	Assign a case (email, or raw user ID)
cx cases unassign <id>	Remove the assignee
cx cases acknowledge <id>	Acknowledge (signals you're working it; stops re-notification)
cx cases unacknowledge <id>	Remove the acknowledgment
cx cases resolve <id> --reason <text>	Resolve a case (irreversible — see below)
cx cases close <id>	Close a case (terminal)
cx cases set-priority <id> --priority <P1..P5>	Override the computed priority
cx cases clear-priority <id>	Remove a priority override
cx cases events list <case-id>	Event timeline (status changes, comments, assignments)
cx cases events get <event-id>	A single event — drill in, e.g. to expand a comment thread
cx cases notifications <case-id> [<case-id> ...]	Notification deliveries (connector, status, time)

Case Lifecycle

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

From state	Allowed transitions	Notes
PENDING_ACTIVATION	→ ACTIVE	System-driven activation; not user-controllable
ACTIVE	→ ACKNOWLEDGED, RESOLVED, CLOSED	Ack is optional; for a false alarm, close directly (skip resolve)
ACKNOWLEDGED	→ ACTIVE, RESOLVED, CLOSED	The only "back" transition: unacknowledge returns it to ACTIVE
RESOLVED	→ CLOSED only	Irreversible — cannot reopen to ACTIVE/ACKNOWLEDGED
CLOSED	(none)	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).
2. 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.
3. Claim — cx cases assign <id> --user you@example.com then cx cases acknowledge <id>.
4. 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.
5. Resolve or close — see below.
6. 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:/...` line printed by any `cx cases` command this session — never fabricate `` 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.