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.
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.
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.
Your data stays in your cluster
One pod. No kwatch cloud.
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
Your data stays in your cluster.
kwatch is one pod. It redacts secrets before anything is stored or sent, and it sends alerts only to the channels you choose. The only other traffic is the license check for Pro and a weekly anonymous ping you can turn off. There is no kwatch cloud reading your logs.
- 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.
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.
Already use Helm? Use the chart instead. Add the repository with helm repo add kwatch https://kwatch.dev/charts and follow 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?
Your alerts, to the channels you choose. With Pro, a daily license check sends a hashed cluster ID, the kwatch version and the node count. Separately, kwatch sends an anonymous adoption ping (hashed cluster ID and version) at most once a week; turn it off with telemetry.enabled: false. Nothing else.
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.