dorgu incidents

List and inspect IncidentMemory resources created by the Dorgu Operator

Overview

The dorgu incidents command group lists and inspects IncidentMemory custom resources on your cluster. These resources are created by the Dorgu Operator when it detects anomalies such as OOMKills, crash loops, or resource constraint violations.

incidents list

Synopsis

dorgu incidents list [flags]

List IncidentMemory resources from the cluster. By default, only active incidents (not Resolved) are shown. Use --all to include resolved incidents.

Flags

Flag	Type	Default	Description
-n, --namespace	string	all namespaces	Filter by namespace
--severity	string	all	Filter by severity: info, warning, critical
--category	string	all	Filter by category (e.g. resource, security)
--phase	string	all	Filter by phase: Detected, Investigating, Resolved, Recurring
--all	bool	false	Include resolved incidents
--limit	int	50	Maximum number of incidents to display
--kubeconfig	string	kubectl’s own resolution: $KUBECONFIG, then ~/.kube/config	Path to kubeconfig file
--json	bool	false	Output as JSON (inherited global flag)

Examples

# List active incidents across all namespaces
dorgu incidents list

# Filter by severity
dorgu incidents list --severity critical

# Filter by namespace and phase
dorgu incidents list -n default --phase Detected

# Show all incidents including resolved, with a higher limit
dorgu incidents list --all --limit 100

# JSON output for scripting
dorgu incidents list --json

Output columns

Column	Description
NAMESPACE	Namespace of the IncidentMemory resource
NAME	Resource name
SEVERITY	info, warning, or critical
CATEGORY	Incident category (e.g. resource, security)
SIGNAL	Detection signal (e.g. OOMKilled, CrashLoopBackOff)
PERSONA	ApplicationPersona the incident relates to. An unattributed incident shows the workload with (no persona) after it, such as report-worker (no persona), because no persona of that name exists.
PHASE	Detected, Investigating, Resolved, or Recurring
AGE	Time since the incident was created

Active Incidents (2)

NAMESPACE  NAME                                  SEVERITY  CATEGORY  SIGNAL            PERSONA                     PHASE          AGE
shop       oom-checkout-api-7c1f                 warning   resource  OOMKilled         checkout-api                Investigating  1h
apps       crashloop-report-worker-unattributed  warning   health    CrashLoopBackOff  report-worker (no persona)  Detected       9m

Unattributed incidents are marked (no persona). Where no single ApplicationPersona claims a workload’s signals, the operator files the incident against the workload rather than folding it into a neighbouring app’s. It is diagnosed, and no remediation is proposed for it. The PERSONA column shows the workload name with (no persona) so a workload never passes for a persona. dorgu health marks them the same way, and its --json output carries attribution on each incident. Separate them with the label:

kubectl get incidentmemory -A -l dorgu.io/attribution=unattributed

The usual fix is to import a persona for the app: dorgu persona import. See one application at a time.

A fault that comes back after its incident resolved appears as a new row named <first-name>-r<N>. A fault that changes shape (not Ready, then restarting, then crash-looping) stays one row whose SIGNAL changes. See one fault, one incident.

---

incidents describe

Synopsis

dorgu incidents describe <name> -n <namespace> [flags]

Display detailed information about a specific IncidentMemory resource, including detection info, root cause analysis, affected resources, and timeline.

Flags

Flag	Type	Default	Description
-n, --namespace	string	required	Namespace of the incident
--kubeconfig	string	kubectl’s own resolution: $KUBECONFIG, then ~/.kube/config	Path to kubeconfig file
--json	bool	false	Output as JSON (inherited global flag)

Examples

# Describe a specific incident
dorgu incidents describe im-default-api-oom-a3f2 -n default

# JSON output
dorgu incidents describe im-default-api-oom-a3f2 -n default --json

Output sections

Section	Description
Phase / Severity / Category	Current incident status and classification
Signal	The detection signal that triggered the incident
Persona	The ApplicationPersona reference (kind, name, namespace). An unattributed incident shows a Subject block instead: its attribution, the workload and namespace, a statement that there is no persona and so no remediation, and the dorgu persona import command that onboards it.
Detection	Source, first seen, last seen timestamps
Affected Resources	Kubernetes resources involved (kind, name, namespace)
Root Cause	The diagnosis summary with confidence score, provider (rule-based or ai-enhanced) and contributing signals
Resolution	Action taken, outcome, and timestamp (if resolved)
Occurrences	Total number of times this incident has been detected

Example output

Model-written text arrives as markdown. The CLI renders it as plain text, keeping every line indented under its label, so a terminal shows no ##, ** or backticks. --json keeps the original text.

Incident: oom-checkout-api-7c1f
═══════════════════════════════

Phase:     Investigating
Severity:  warning
Category:  resource
Signal:    OOMKilled

Persona:
  Kind:      ApplicationPersona
  Name:      checkout-api
  Namespace: shop

Detection:
  Source:     health-check
  First Seen: 2026-11-09 08:00:00 (1h ago)
  Last Seen:  2026-11-09 08:12:00 (48m ago)

Affected Resources:
  - Deployment/checkout-api (shop)

Root Cause:
  Summary:    The checkout-api container is being OOM-killed: its memory limit of 256Mi is below what it needs under load.

              - Raise the memory limit.
              - Watch for a leak if it recurs.
  Confidence: 90%
  Provider:   ai-enhanced
  Contributing Signals:
    - OOMKilled: container checkout-api terminated with reason OOMKilled
    - CrashLoopBackOff: container is in CrashLoopBackOff

Occurrences: 4

For an unattributed incident the Persona block becomes:

Subject:
  Attribution: unattributed
  Workload:    report-worker
  Namespace:   apps
  There is no ApplicationPersona for this workload, so this incident is recorded against the
  workload itself. Dorgu diagnoses it but proposes no remediation.
  To onboard it: dorgu persona import -n apps

Requires the Dorgu Operator to be installed on the cluster. If the IncidentMemory CRD is not registered, the command will report an error with installation instructions.