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
- Inspect —
cx cases get <id>. The payload includesgroupings,
labels, impactedEntities, kpiBreaches, aiSummary, and both priorityDetails.system (computed) and priorityDetails.override (user-set).
- 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.
- Claim —
cx cases assign <id> --user you@example.comthen
cx cases acknowledge <id>.
- 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.
- Resolve or close — see below.
- 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 --userand in all output. resolveis irreversible andcloseis terminal — confirm before resolving;
for false alarms close from ACTIVE directly.
- Always supply a resolution reason unless
--no-reasontruly 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.
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.







