Incidents
Incident triage.
For active incidents, recent changes, and the fleet context an operator needs before escalation.
Before you start: You need a connected profile, so xyte-cli ops watch incidents can read tenant state. Run Setup readiness first. New here? See the glossary.
Ask an agent
Ask for the incident picture, not a command name. The agent will read active incidents, compare the watch output, and save fleet context for the handoff.
Show me active incidents and what changed since yesterday.What the agent will do
- DiscoverCheck accessConfirm xyte-cli can read incident state.
- InspectRead incidentsCapture active incidents and recent frames.
- ChooseSet time windowUse the requested time window, or ask before choosing a different one.
- WriteSave handoff filesWrite incident frames and source JSON when useful.
- ReturnExplain changeSummarize active count, changes, files, and next move.
Ask how it works first
Ask this when you want to understand the watch command before using it in a handoff or recurring job.
How do I set a watch on my incidents using xyte-cli?
What does ops watch incidents return?
How do I compare incidents since yesterday?Goal
The incident watch command gives a normalized incident frame. Run it once for a quick count, or poll briefly to detect additions, removals, and updates. Use fleet and deep-dive outputs when the incident needs context.
Commands
-
Get the current active incident snapshot
This is the fastest way to answer "what is active right now?"
xyte-cli ops watch incidents \ --tenant <tenant-id> \ --profile incidents-active \ --once \ --output json \ --strict-json -
Watch a short change window
Use a bounded watch for live triage. The output file is NDJSON so every frame can be read independently.
xyte-cli ops watch incidents \ --tenant <tenant-id> \ --profile incidents-active \ --interval-ms 2000 \ --max-polls 30 \ --output json \ --strict-json \ --out ./artifacts/xyte-watch.incidents.ndjson -
Add fleet context before deciding what to do
These files answer whether the incident is isolated or part of a broader tenant problem.
xyte-cli ops inspect fleet \ --tenant <tenant-id> \ --output json \ --out ./artifacts/xyte-fleet.triage.json xyte-cli ops inspect deep-dive \ --tenant <tenant-id> \ --window 24 \ --output json \ --out ./artifacts/xyte-deep-dive.triage.json
Read the output
snapshotis the baseline incident set.deltameans an incident was added, removed, or updated since the previous successful frame.heartbeatmeans polling worked and nothing changed.errormeans the poll failed; keep the previous good baseline and retry after checking setup.
{
"schemaVersion": "xyte.watch.frame.v1",
"eventType": "snapshot",
"profile": "incidents-active",
"tenantId": "<tenant-id>",
"summary": {
"total": 12,
"added": 0,
"removed": 0,
"updated": 0,
"changed": 0
}
}A useful handoff names the active count, new or changed incidents, and the fleet context file. If frames repeat errors, the baseline is stale, or counts do not match the intended filters, fix those inputs before escalating.
Make this repeatable
# Environment
XYTE_TENANT=<tenant-id>
# Rerun path
xyte-cli ops watch incidents --tenant "$XYTE_TENANT" --profile incidents-active --once --output json --strict-json
xyte-cli ops inspect fleet --tenant "$XYTE_TENANT" --output json --out ./artifacts/xyte-fleet.triage.jsonIf it fails
Compare filters first: status, date range, page size, and whether the UI hides older active incidents.
Run xyte-cli config doctor --tenant <tenant-id> --format text, then retry with --once.
Use --max-polls. Do not leave an unbounded watch running in a support handoff.