Kubius · Events

See Kubernetes events where they matter

Events scroll past and expire, and kubectl get events is a wall of text. Kubius shows them live against the resource they belong to - a pod, a node, a deployment - newest first, so you catch the warning that explains the problem.

Works with Google GKE, Amazon EKS, Azure AKS, DigitalOcean, self-managed & more · macOS Sonoma (14) or later

Events, in context

Per-resource, not a firehose

Each resource shows its own events, so you read the story of that pod or node instead of scrolling the whole cluster's stream.

Live and ordered

Events appear as they happen, newest first, so a fresh warning or restart surfaces immediately.

Warnings stand out

Warning events - BackOff, FailedScheduling, Unhealthy, OOM - are easy to distinguish from routine activity.

Tied to the object

Events are matched to the resource by name, so what you see genuinely belongs to what you're looking at (no cross-object noise).

Node and workload events too

Not just pods - see node events (pressure, NotReady, reboots) and workload events (scaling, rollouts) where they belong.

Nothing to install

Read live from the Kubernetes API with your kubeconfig - no agents, no event exporter.

Simple, one-time pricing

Pay once. No subscription.

One-time licence from €49 - no subscription. 14-day free trial, no card required.

Free 14-day trial · macOS Sonoma (14) or later · No agents, nothing to install in-cluster

Questions, answered

How is this better than kubectl get events?

kubectl dumps every event in the namespace as unsorted text. Kubius shows each resource's own events, live and newest-first, right on that resource - so the warning that explains a problem is next to the thing that has it.

Can I see events for nodes and deployments, not just pods?

Yes. Events are shown against pods, nodes, deployments and other resources, so you get scheduling, pressure, scaling and rollout events where they're relevant.

Are events matched reliably to the right object?

Events are matched by the involved object's name, which is the reliable field across providers, so the events you see belong to the resource you're viewing.

Do I need anything in the cluster?

No - Kubius reads events straight from the Kubernetes API using your kubeconfig.

Catch the event that explains it