03:07 · #prod-alerts · 47 new messages
Fifty alerts.
One cause.
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
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 pod failures and NotReady nodes; Pro covers everything below.
Pods
Crash loops, OOM kills, image pulls, Pending
Nodes
NotReady, pressure, draining
Workloads
Stuck rollouts, failed Jobs, missed CronJobs
Storage
Pending claims, attach failures, full volumes
Network
Services with no endpoints, Ingress, policies
Certificates
Expiring and invalid TLS
Control plane
API server, etcd, DNS, webhooks
Custom resources
Failing conditions on CRDs
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 talks only to the channels you choose. 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.
Paste one line.
Answer a few questions.
Run it again any time to upgrade, change settings or manage your license.
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 company.
Community
Free forever. No account.
Crash loops, OOM kills, Pending pods and NotReady nodes, explained in one line, 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
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. Nothing else.
What permissions does it need?
Read access to the resources it watches. 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 before we charge anything. If that changes, you'll hear well in advance.