03:07 · #prod-alerts · 47 new messages
Fifty alerts.
One cause.
When something breaks in your Kubernetes cluster, kwatch tells you what broke, why, and what to do, in Slack, Discord, email and 50+ other channels.
kwatch runs inside your Kubernetes cluster, traces every failure back to what started it, and sends one message: what broke, why, who changed it, and what to do next.
checkout-api is crash-looping because a ConfigMap changed 4 minutes ago.
- Why
DB_HOSTpoints to a host that doesn't resolve- Who
- deploy-bot, via Argo CD
- Impact
- payments, cart
- Next
- Roll back
checkout-config
Illustrative example.
Root cause, without your data leaving the cluster.
kwatch analyzes events and logs where they live.
Only optional anonymous usage stats and Pro license checks reach kwatch.dev. Never cluster names, pod names, logs or events. Alerts go only to the channels you set up. What is sent
- One pod. A small volume for state, nothing else to run.
- 50+ channels. Slack, Teams, PagerDuty, Opsgenie, email, webhooks.
- Source available. Read every line on GitHub, under ELv2.
| What | When | Contains | Control |
|---|---|---|---|
| Anonymous usage stats | At most once a week | An anonymous ID derived from your cluster (a one-way hash that can't be traced back to the cluster or linked to your license) and the kwatch version | On by default; turn off with telemetry.enabled: false or KWATCH_TELEMETRY=false |
| Pro license check | Once a day, Pro only | License ID, hashed cluster ID, kwatch version, node count | Part of Pro; Community sends none |
Never sent: cluster names, namespaces, pod names, logs or events.
How it works in 30 seconds
Step 1
Install
Run one command. It asks a few questions.
Step 2
It watches
kwatch runs as one small pod in your cluster and keeps a live map of what depends on what.
Step 3
You hear
When something breaks you get one clear message: what broke, why, and what to do.
The example alert above is what step 3 looks like.
Root cause first
kwatch follows a failure upstream and names the one cause.
Your data stays in your cluster
kwatch analyzes events and logs where they live.
Quiet by default
One message, then silence until something new is true.
Who changed what
See who changed what, and when.
The next step
Every message ends with the command to run.
50+ channels
Slack, Teams, PagerDuty, email, webhooks and more.
How it works
It follows the trail, the way you would. In seconds.
1 — watch
Keeps a live map of your cluster
Pods, workloads, nodes, volumes, configs, services and certificates, how they connect, and every change made to them, with who made it.
2 — trace
Walks back to the first domino
When something fails, it follows the links upstream and only blames what is actually broken or recently changed.
- Pod checkout-api-7f9c · CrashLoopBackOff
- Deployment checkout-api · healthy before 03:03
- Node worker-3 · healthy
- ConfigMap checkout-config · changed 03:03 ← cause
3 — tell
Sends one message, then stays quiet
Symptoms join one incident. You hear again only when something material changes, and once more when it's resolved.
What it catches
The failures that wake people up.
Built in, no rules to write. Community covers apps that crash and servers that go down; Pro covers everything below.
Apps that keep crashing
Crash loops, out-of-memory kills, image pull failures and pods stuck waiting to start
CrashLoopBackOff, OOMKilled, Pending
Servers that go down
A machine in your cluster stops responding, runs low on resources or is being drained
Node NotReady, pressure, draining
Deploys that never finish
A new version that does not roll out, jobs that fail and scheduled jobs that never ran
Stuck rollouts, failed Jobs, missed CronJobs
Disks that fill up or will not attach
Storage requests that stay pending or cannot attach, and volumes that are almost full
PVC Pending, attach failures
Services nobody can reach
A service with nothing behind it, or traffic rules that block it
No endpoints, Ingress, NetworkPolicy
Certificates about to expire
Security certificates that are close to expiring or already invalid
TLS certificates
The cluster itself
The parts that run Kubernetes, DNS, and the checks that approve or reject changes
API server, etcd, DNS, admission webhooks
Custom add-ons
Failing conditions on resources that other tools add to your cluster
Custom resources (CRDs)
New to Kubernetes? Plain-English glossary
- Cluster
- The group of machines that runs your apps.
- Node
- One machine in the cluster.
- Pod
- A running copy of an app.
- Namespace
- A named area of the cluster, often one per team or app.
- CrashLoopBackOff
- A pod keeps starting, failing and restarting.
- OOMKilled
- A pod used more memory than allowed and was stopped.
- RBAC
- Kubernetes permissions. It decides what kwatch may read.
- Helm
- A package manager for Kubernetes, an alternative way to install.
- CRD
- A custom resource definition, an extra kind of object that a tool adds to the cluster.
- Rollout
- Replacing the running version of an app with a new one.
- ConfigMap
- A settings object an app reads, such as a database address.
- PDB and HPA
- A PodDisruptionBudget limits how many copies of an app may be down at once. A HorizontalPodAutoscaler adds or removes copies as load changes.
One incident, one thread
Quiet by default.
No repeats every five minutes, no flapping storms. kwatch waits for failures to settle, merges what belongs together and speaks when there is news.
Updates arrive in one thread on Slack with Pro; in Community they arrive as short follow-up messages.
03:07
Opened: checkout-api crash-looping, cause found
03:11
Update: cart-svc now affected too
03:16
Fix detected: checkout-config rolled back
03:21
Resolved after 14 minutes
One command, and it
walks you through it.
The installer checks your cluster before it changes anything. Run it again any time to upgrade, change settings or manage your license.
Prefer Helm? See the chart guide.
Free. And Pro is free too.
While kwatch is in early access, Pro licenses are free for 3 months and we may renew them. Up to 2 clusters per account or company. No payment details.
Community
Free forever. No account.
Apps that keep crashing (crash loops, out-of-memory kills), pods stuck waiting and servers that go down (NotReady nodes), explained in one line and sent to one channel.
InstallPro
Free during early access.
Every detector. The full proof and who made the change. Unlimited channels with routing and threads. History, audit log, maintenance windows and runbooks.
Fair questions
Do I need to be a Kubernetes expert?
No. One command, and it walks you through it with plain questions. It checks your cluster before it changes anything. Alerts say what broke, why and what to do next in plain words, with the technical names alongside for people who want them.
Will it work on my cluster?
kwatch runs on any conformant Kubernetes cluster. The installer checks your cluster before it changes anything.
Does it replace Prometheus?
No. Keep your metrics. kwatch answers a different question: when something breaks, what caused it and what to do.
What leaves my cluster?
Only optional anonymous usage stats and Pro license checks reach kwatch.dev. Usage stats go at most once a week and contain an anonymous ID derived from your cluster (a one-way hash that cannot be traced back to the cluster or linked to your license) and the kwatch version; turn them off with telemetry.enabled: false. A Pro license check goes once a day and contains the license ID, a hashed cluster ID, the kwatch version and the node count. Community sends none. Never cluster names, namespaces, pod names, logs or events. Alerts go only to the channels you set up.
What permissions does it need?
Read access to the resources it watches, through Kubernetes permissions (RBAC) that decide what kwatch may read. It writes only its own lock and license record in its own namespace, and never changes your workloads.
Why is Pro free?
We want kwatch proven on real clusters first. If that ever changes, you will hear well in advance.