lookout triage events

Deduped chronological event timeline: kubectl get events, but collapsed by (object, reason family) over a workload’s whole owner-reference tree, with HPA rescale-oscillation (thrash) detection.

MCP tool: k8s_event_timeline

Usage

lookout triage events [flags]

Flags

Flag	Type	Default	Meaning
--hpa-window	duration	30m	report event.hpa_thrash when enough scale-direction changes fall inside a window this long
--hpa-flips	int	2	scale-direction changes within —hpa-window that count as thrash (2 = up→down→up)

Common flags (every lookout command)

Flag	Type	Default	Meaning
--namespace	string	—	limit the scan to one namespace
-A	bool	—	scan all namespaces
--workload	string	—	target one workload as <Kind>/<namespace>/<name>, e.g. Deployment/prod/api
--since	duration	—	how far back to look (0 = command default)
--format	string	logfmt	output format: logfmt|json (one record per line either way)
--timeout	duration	10s	abort the invocation after this long (exit 1)
--kubeconfig	string	—	path to a kubeconfig file, instead of $KUBECONFIG / ~/.kube/config
--context	string	—	kubeconfig context to read, instead of its current-context. Selects a cluster for THIS invocation only — nothing is written back — so concurrent invocations can target different clusters. Reported as context=<name> in the summary line
--exemptions	string	—	path to a git-reviewed exemption file (YAML); covered findings are ANNOTATED with their reason and expiry and counted as exempt=<n> in the summary, never dropped

Finding kinds

Every kind= this command can emit, and the severities it carries them at. Nothing else appears in its output; a kind absent from a run means the check looked and found nothing. See the finding-kind glossary for the whole vocabulary.

Kind	Severity	Claim
event.warning	warning	one collapsed timeline entry for a Warning-type event family on a subject
event.normal	info	one collapsed timeline entry for a Normal-type event family — context for the warnings around it, not a problem on its own
event.hpa_thrash	warning	an HPA changed scale direction at least —hpa-flips times inside —hpa-window: the autoscaler is fighting itself

Output fields

Beyond the shared envelope fields (kind, severity, namespace, kind_of_object, name, reason, message, fingerprint, exempt_reason, exempt_expires):

Field	Meaning
count	events collapsed into this timeline entry: k8s per-event repeat counts summed across the entry’s reason family
first_seen	RFC3339 timestamp of the entry’s oldest activity
last_seen	RFC3339 timestamp of the entry’s newest activity (the timeline sort key)
source	reporting component (kubelet, horizontal-pod-autoscaler, …)
variants	raw Event.Reason values collapsed into this entry, comma-separated (present only when a reason family merged more than one)
replicas	event.hpa_thrash: the chronological replica sequence recovered from SuccessfulRescale events, e.g. 2->6->2->6
flips	event.hpa_thrash: most scale-direction changes observed inside one —hpa-window
window	event.hpa_thrash: the —hpa-window the flips were counted in
target	event.hpa_thrash: the HPA’s scaleTargetRef as Kind/name (when the HPA object was readable)

Output contract

Output: one finding per line (logfmt; —format=json for one JSON object per line), keys in fixed order; healthy resources emit nothing. The final line is always the summary: scanned= findings= elapsed= — findings=0 with a summary present means “scanned and healthy”; a stream without a summary line is void. Exit 0 data, 1 runtime error (diagnostics on stderr only), 2 usage.

Examples

lookout triage events --workload=Deployment/prod/api
lookout triage events --workload=Pod/prod/api-6d5f8c-x2v9k --since=30m
lookout triage events --namespace=prod
lookout triage events -A --since=2h --format=json
lookout triage events --workload=Deployment/prod/api --hpa-window=15m --hpa-flips=4