👀 monitor & detect crashes in your Kubernetes(K8s) cluster instantly
See the code
kwatch is the on-call teammate for your Kubernetes cluster. When something breaks, it finds the one thing that caused it and tells your team in plain words, with the command to fix it.
Get started · Website · Docs · Discord
A release went out. Now pods are crash looping, a Service has no endpoints, the Ingress returns 503s, and two other apps are failing their health checks. Every alert is true. None of them tells you why. So you open a terminal and start digging.
| Typical alerts without kwatch | With kwatch |
|---|---|
|
|
What broke, why, who changed it, what else is hit, and how to fix it, in one message, before you have even opened your laptop. When it is fixed, you hear about it once:
✅ api in shop (prod-eu-1) is healthy again. It was down for eight
minutes.
🎯 The cause, not the symptomskwatch follows a failure back through everything it depends on, and names the root: a bad release, a full node, an expired certificate, a database outside the cluster. Twenty symptoms become one incident. |
🔕 Quiet by defaultSuccessful rollouts, scaling, node drains, finished Jobs and the odd pod restart never wake anyone. Updates are sent only when something new is true. A storm of 1,000 failing pods from one cause is at most 3 messages. |
🧠 Knows what changedEvery rollout, config edit and image update goes on a timeline with who made it, so the message can say "after alice's 14:02 release". It even remembers changes made while kwatch itself was restarting. |
🛠️ Tells you what to runEach message ends with the next step: the exact |
🌐 Sees the whole clusterEvery Kubernetes resource, Gateway API, snapshots and your own CRDs, with the links between them. If it has a status, kwatch understands it. |
🔒 Yours, in your clusterOne small Pod, read-only access, no account, no SaaS. Your cluster data never leaves your cluster except as the alerts you configure. |
flowchart LR
A["👀 Watch<br/>every resource<br/>and every change"] --> B["🩺 Detect<br/>what is unhealthy"]
B --> C["🎯 Explain<br/>follow failures upstream<br/>to the fewest causes"]
C --> D["📨 Tell<br/>one message per cause,<br/>update only on news"]
One node runs low on memory and starts evicting pods. Here is the same incident in your channel, twice.
Before: one alert per pod
🔥 Pod api-7d9f-x2k CrashLoopBackOff
🔥 Pod orders-5b2c-p1z CrashLoopBackOff
⚠️ Pod cart-6c8d-k7w Readiness probe failed
⚠️ Deployment api unavailable
🔥 Pod api-7d9f-x2k restarted (5 times)
⚠️ Node pool-a-n1 NotReady
✅ Node pool-a-n1 Ready
⚠️ Node pool-a-n1 NotReady
... 14 more
After: one message with the cause, then one when it is over
Messages are written as short lines, with the resource names in bold, text from your pods in code and the command in a code block. Slack, Discord, Telegram, Jira and the other chat and ticket providers show it as below; SMS, push and pager providers get the same lines as plain text.
🟠 **Node n1** (**prod-eu-1**) is low on memory. All of its dependents are failing.
Replicas that do not depend on it are healthy.
**cart**, **orders** and **api** in **shop** are affected as well.
To check the node's conditions and recent events, run
kubectl describe node n1
✅ **Node n1** (**prod-eu-1**) is ready again. It was failing for ten minutes.
The same goes for the other incidents you care about:
🟠 **api** is failing in **shop** (**prod-eu-1**) after the 10:01 release of registry.example.com/api:2.3.
The previous image was registry.example.com/api:2.2.
It fails with `panic: missing key DB_PASSWORD_V2`.
To see the rollout state, run
kubectl rollout status deployment/api -n shop
Messages that list several problems are short lists, the ones that need attention first and what resolved on one line. kwatch reports what is happening, not what could happen: advice such as a single replica or a missing probe is never listed:
🟡 **kwatch digest** · staging — 2 problems · 5 resolved
**Problems**
• Node **ip-10-0-67-211** — failing again
• Service **ingress-nginx** (**kube-addons**) — Kubernetes reported FailedDeployModel 3 times in the last quarter hour
✅ 5 resolved since last digest: accounts, assets, comms +2
🟠 **kwatch** · prod-eu-1 — 2 new problems at the same time
**Problems**
• **ledger** in **billing** keeps crashing
• **checkout** in **orders** keeps crashing
_Each gets its own message when it changes or resolves._
One message per problem, with its cause and the command to fix or check it. Known and low-priority problems stay quiet, and the resolve message tells you what happened.
When five apps fail because a database outside the cluster is down, kwatch blames the database, not the apps:
🟠 api in shop (prod-eu-1) keeps crashing because external endpoint
db.example.com:5432 refuses connections. It fails with "dial tcp
db.example.com:5432: connect: connection refused". Every error mentions it.
cart, search, auth and one other are affected as well. To read the output
of the last crash, run
kubectl logs api-6d4f-0 -c app -n shop --previous
When a node disappears:
🔴 Node n1 (prod-eu-1) has not reported for about two minutes. It reports
"Kubelet stopped posting node status". To check the node's conditions and
recent events, run kubectl describe node n1
When kwatch is not sure, it says so instead of guessing. One emoji tells you how urgent it is: 🔴 page · 🟠 notify · 🟡 low · ✅ resolved.
/bin/bash -c "$(curl -fsSL https://kwatch.dev/kwatch.sh)"
The installer asks which cluster and which channel (Slack, Teams, PagerDuty, …), stores the credentials in a Kubernetes Secret, installs kwatch and checks that it is running. Run it again any time to upgrade, change settings or uninstall.
Prefer Helm? helm repo add kwatch https://kwatch.dev/charts, then follow
the chart guide.
56 destinations, including Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, email, PagerDuty, Opsgenie, incident.io, Jira, Datadog and plain webhooks. Paging tools get a stable key, so the same problem always updates the same page and closes it when it is fixed. See all channels →
| 📦 Apps | Crash loops, OOM kills, bad rollouts, stuck Jobs and CronJobs, missing replicas |
| 🗓️ Scheduling | Pods that cannot be placed, quota limits, affinity and taint mismatches |
| 🖥️ Nodes | Lost or not-ready nodes, memory, disk and PID pressure |
| 🌐 Network | Services without endpoints, broken Ingress and Gateway routes, failing webhooks, unreachable external endpoints |
| 💾 Storage | Nearly full volumes, failed attachments, stuck claims |
| 🔐 Config | Missing or rotated Secrets and ConfigMaps, image pull failures, expiring certificates |
| 🧩 Your CRDs | Anything that reports standard status conditions |
Every change to kwatch is replayed against a library of real failure scenarios, plus a hidden set nobody is allowed to tune for. The build fails if it gets worse:
| We promise | And CI checks |
|---|---|
| It names the right cause | ≥ 90% of scenarios, ≥ 80% of the hidden set |
| It rarely claims a wrong cause with confidence | ≤ 5% |
| It never alerts on normal operations | 0 alerts |
| It is fast | page in ≤ 2 min, notify in ≤ 5 min |
| It stays small | 5,000 pods and 500 nodes in 512 MiB of memory |
No. kwatch answers "what just broke and why". Keep Prometheus, Grafana and Loki for metrics, trends and dashboards; kwatch needs no rules and works next to them.
Only as the alerts you configure. Secrets and tokens are redacted from logs
and messages. kwatch also sends a weekly anonymous ping (a hashed cluster ID
and its version, nothing else) so we know how many clusters use it; turn it
off with telemetry.enabled: false.
Read-only access to cluster state. It writes only its own Lease, its
state file, and SelfSubjectAccessReviews for its permission audit (not
persisted). It never gets pods/exec or nodes/proxy. A least-privilege
mode and a watch.secrets: false opt-out are available.
kwatch is free to use in your own clusters. It runs as one Pod with a 512 MiB memory limit and a 2 GiB volume for its state.
It picks up where it left off: open incidents are not announced again, queued alerts are still sent, and changes made while it was down are still used to explain failures. It runs as one replica (no HA) and delivers alerts at least once. See production operations.
Yes: namespace filters, silences, maintenance annotations, severity
overrides, runbook links, an hourly message budget per channel, and
configuration through a KwatchConfig resource (kwatch restarts to apply it).
See the
configuration guide.
kwatch is built in the open. Report a bug, suggest an idea, or send a pull request. New contributors can start with the plain-English architecture guide and step-by-step guides for adding a detector, a propagation rule or a scenario.
Open an issue · Join Discord · CONTRIBUTING.md
If kwatch saves you a night, ⭐ the repo so others can find it.
Source available under the Elastic License 2.0: use it free in
your own clusters, read and change the code, and share it. You may not offer
kwatch as a hosted service or remove its license checks. Releases up to and
including v1.0.0-rc.10 remain under the MIT License. See
licensing.
Overall
Maintained
Code review
Contributors
Go module
Latest release
Releases this year
13,355 followers · starred Mar 2022
233 followers · starred Aug 2026
605 followers · starred Dec 2021
674 followers · starred Nov 2023
👀 monitor & detect crashes in your Kubernetes(K8s) cluster instantly
See the code
kwatch is the on-call teammate for your Kubernetes cluster. When something breaks, it finds the one thing that caused it and tells your team in plain words, with the command to fix it.
Get started · Website · Docs · Discord
A release went out. Now pods are crash looping, a Service has no endpoints, the Ingress returns 503s, and two other apps are failing their health checks. Every alert is true. None of them tells you why. So you open a terminal and start digging.
| Typical alerts without kwatch | With kwatch |
|---|---|
|
|
What broke, why, who changed it, what else is hit, and how to fix it, in one message, before you have even opened your laptop. When it is fixed, you hear about it once:
✅ api in shop (prod-eu-1) is healthy again. It was down for eight
minutes.
🎯 The cause, not the symptomskwatch follows a failure back through everything it depends on, and names the root: a bad release, a full node, an expired certificate, a database outside the cluster. Twenty symptoms become one incident. |
🔕 Quiet by defaultSuccessful rollouts, scaling, node drains, finished Jobs and the odd pod restart never wake anyone. Updates are sent only when something new is true. A storm of 1,000 failing pods from one cause is at most 3 messages. |
🧠 Knows what changedEvery rollout, config edit and image update goes on a timeline with who made it, so the message can say "after alice's 14:02 release". It even remembers changes made while kwatch itself was restarting. |
🛠️ Tells you what to runEach message ends with the next step: the exact |
🌐 Sees the whole clusterEvery Kubernetes resource, Gateway API, snapshots and your own CRDs, with the links between them. If it has a status, kwatch understands it. |
🔒 Yours, in your clusterOne small Pod, read-only access, no account, no SaaS. Your cluster data never leaves your cluster except as the alerts you configure. |
flowchart LR
A["👀 Watch<br/>every resource<br/>and every change"] --> B["🩺 Detect<br/>what is unhealthy"]
B --> C["🎯 Explain<br/>follow failures upstream<br/>to the fewest causes"]
C --> D["📨 Tell<br/>one message per cause,<br/>update only on news"]
One node runs low on memory and starts evicting pods. Here is the same incident in your channel, twice.
Before: one alert per pod
🔥 Pod api-7d9f-x2k CrashLoopBackOff
🔥 Pod orders-5b2c-p1z CrashLoopBackOff
⚠️ Pod cart-6c8d-k7w Readiness probe failed
⚠️ Deployment api unavailable
🔥 Pod api-7d9f-x2k restarted (5 times)
⚠️ Node pool-a-n1 NotReady
✅ Node pool-a-n1 Ready
⚠️ Node pool-a-n1 NotReady
... 14 more
After: one message with the cause, then one when it is over
Messages are written as short lines, with the resource names in bold, text from your pods in code and the command in a code block. Slack, Discord, Telegram, Jira and the other chat and ticket providers show it as below; SMS, push and pager providers get the same lines as plain text.
🟠 **Node n1** (**prod-eu-1**) is low on memory. All of its dependents are failing.
Replicas that do not depend on it are healthy.
**cart**, **orders** and **api** in **shop** are affected as well.
To check the node's conditions and recent events, run
kubectl describe node n1
✅ **Node n1** (**prod-eu-1**) is ready again. It was failing for ten minutes.
The same goes for the other incidents you care about:
🟠 **api** is failing in **shop** (**prod-eu-1**) after the 10:01 release of registry.example.com/api:2.3.
The previous image was registry.example.com/api:2.2.
It fails with `panic: missing key DB_PASSWORD_V2`.
To see the rollout state, run
kubectl rollout status deployment/api -n shop
Messages that list several problems are short lists, the ones that need attention first and what resolved on one line. kwatch reports what is happening, not what could happen: advice such as a single replica or a missing probe is never listed:
🟡 **kwatch digest** · staging — 2 problems · 5 resolved
**Problems**
• Node **ip-10-0-67-211** — failing again
• Service **ingress-nginx** (**kube-addons**) — Kubernetes reported FailedDeployModel 3 times in the last quarter hour
✅ 5 resolved since last digest: accounts, assets, comms +2
🟠 **kwatch** · prod-eu-1 — 2 new problems at the same time
**Problems**
• **ledger** in **billing** keeps crashing
• **checkout** in **orders** keeps crashing
_Each gets its own message when it changes or resolves._
One message per problem, with its cause and the command to fix or check it. Known and low-priority problems stay quiet, and the resolve message tells you what happened.
When five apps fail because a database outside the cluster is down, kwatch blames the database, not the apps:
🟠 api in shop (prod-eu-1) keeps crashing because external endpoint
db.example.com:5432 refuses connections. It fails with "dial tcp
db.example.com:5432: connect: connection refused". Every error mentions it.
cart, search, auth and one other are affected as well. To read the output
of the last crash, run
kubectl logs api-6d4f-0 -c app -n shop --previous
When a node disappears:
🔴 Node n1 (prod-eu-1) has not reported for about two minutes. It reports
"Kubelet stopped posting node status". To check the node's conditions and
recent events, run kubectl describe node n1
When kwatch is not sure, it says so instead of guessing. One emoji tells you how urgent it is: 🔴 page · 🟠 notify · 🟡 low · ✅ resolved.
/bin/bash -c "$(curl -fsSL https://kwatch.dev/kwatch.sh)"
The installer asks which cluster and which channel (Slack, Teams, PagerDuty, …), stores the credentials in a Kubernetes Secret, installs kwatch and checks that it is running. Run it again any time to upgrade, change settings or uninstall.
Prefer Helm? helm repo add kwatch https://kwatch.dev/charts, then follow
the chart guide.
56 destinations, including Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, email, PagerDuty, Opsgenie, incident.io, Jira, Datadog and plain webhooks. Paging tools get a stable key, so the same problem always updates the same page and closes it when it is fixed. See all channels →
| 📦 Apps | Crash loops, OOM kills, bad rollouts, stuck Jobs and CronJobs, missing replicas |
| 🗓️ Scheduling | Pods that cannot be placed, quota limits, affinity and taint mismatches |
| 🖥️ Nodes | Lost or not-ready nodes, memory, disk and PID pressure |
| 🌐 Network | Services without endpoints, broken Ingress and Gateway routes, failing webhooks, unreachable external endpoints |
| 💾 Storage | Nearly full volumes, failed attachments, stuck claims |
| 🔐 Config | Missing or rotated Secrets and ConfigMaps, image pull failures, expiring certificates |
| 🧩 Your CRDs | Anything that reports standard status conditions |
Every change to kwatch is replayed against a library of real failure scenarios, plus a hidden set nobody is allowed to tune for. The build fails if it gets worse:
| We promise | And CI checks |
|---|---|
| It names the right cause | ≥ 90% of scenarios, ≥ 80% of the hidden set |
| It rarely claims a wrong cause with confidence | ≤ 5% |
| It never alerts on normal operations | 0 alerts |
| It is fast | page in ≤ 2 min, notify in ≤ 5 min |
| It stays small | 5,000 pods and 500 nodes in 512 MiB of memory |
No. kwatch answers "what just broke and why". Keep Prometheus, Grafana and Loki for metrics, trends and dashboards; kwatch needs no rules and works next to them.
Only as the alerts you configure. Secrets and tokens are redacted from logs
and messages. kwatch also sends a weekly anonymous ping (a hashed cluster ID
and its version, nothing else) so we know how many clusters use it; turn it
off with telemetry.enabled: false.
Read-only access to cluster state. It writes only its own Lease, its
state file, and SelfSubjectAccessReviews for its permission audit (not
persisted). It never gets pods/exec or nodes/proxy. A least-privilege
mode and a watch.secrets: false opt-out are available.
kwatch is free to use in your own clusters. It runs as one Pod with a 512 MiB memory limit and a 2 GiB volume for its state.
It picks up where it left off: open incidents are not announced again, queued alerts are still sent, and changes made while it was down are still used to explain failures. It runs as one replica (no HA) and delivers alerts at least once. See production operations.
Yes: namespace filters, silences, maintenance annotations, severity
overrides, runbook links, an hourly message budget per channel, and
configuration through a KwatchConfig resource (kwatch restarts to apply it).
See the
configuration guide.
kwatch is built in the open. Report a bug, suggest an idea, or send a pull request. New contributors can start with the plain-English architecture guide and step-by-step guides for adding a detector, a propagation rule or a scenario.
Open an issue · Join Discord · CONTRIBUTING.md
If kwatch saves you a night, ⭐ the repo so others can find it.
Source available under the Elastic License 2.0: use it free in
your own clusters, read and change the code, and share it. You may not offer
kwatch as a hosted service or remove its license checks. Releases up to and
including v1.0.0-rc.10 remain under the MIT License. See
licensing.
Overall
Maintained
Code review
Contributors
Go module
Latest release
Releases this year
13,355 followers · starred Mar 2022
233 followers · starred Aug 2026
605 followers · starred Dec 2021
674 followers · starred Nov 2023