“Another Kubernetes observability tool? The market’s saturated.” We heard it before we wrote a line of code, and it’s a fair thing to say. Datadog, Grafana, New Relic, and a dozen others already own that real estate. So this post is the honest answer to the obvious question: why build KubeBolt at all?
The short version: the category isn’t saturated, it’s miscategorized. Everyone is selling observability. Almost no one is selling operation. That gap is where KubeBolt lives.
Three incumbents, three blind spots
Each of the big players is excellent at what it was built for — and that origin is exactly what holds it back for Kubernetes operations.
- Datadog is a generalist. It monitors everything: VMs, serverless, databases, APM, logs. That breadth is its moat and its tax. You pay for a platform that treats your cluster as one more data source, not as the thing your product runs on.
- Grafana is a visualization layer. It’s brilliant at drawing the graph — but the graph is the end of its job. What happens after the line goes red is still entirely on you.
- New Relic and the rest of the APM crowd are application-centric. They tell you a request is slow; they don’t tell you the
PodDisruptionBudgetis blocking your drain.
None of these are bad products. They’re the wrong shape for the job of running Kubernetes — and they can’t change shape without rewriting themselves, because their pricing, data model, and UX all assume a generalist, observe-only world.
The gap: operate, don’t just observe
A dashboard that turns red tells you a symptom exists. It doesn’t gather context, decide what to do, or act. Every on-call engineer knows the gap between “something is wrong” and “it’s fixed” — and that gap is where the night goes.
KubeBolt is built to close it. The same surface that shows you a CrashLoopBackOff lets you fix it: set image, scale, roll back, drain a node — under RBAC, with an audit log on every mutation. Above that sits assisted resolution (Kobi proposes the fix, you approve) and autonomous remediation (Autopilot acts within guardrails and writes the postmortem). Observability is table stakes; what you do after the alert is the product.
Pricing that scales with your infra, not your headcount
There’s a second, quieter reason the incumbents can’t follow us here: how they charge.
Most observability tools bill per active user or per host, on top of data volume. As your team grows, the bill grows with headcount — not with the real complexity of your system. That’s great for the vendor and backwards for you: the engineers you want poking at production are the ones the pricing model punishes.
KubeBolt prices per resource. Your bill tracks the infrastructure you actually run, and inviting your whole team costs nothing extra. It’s a small decision with a large consequence — and one a per-seat incumbent can’t copy without breaking its own revenue model.
Why a small team can win this
The instinct is that you can’t out-build Datadog. You don’t have to. Datadog has to do everything adequately. We do one thing — Kubernetes operations — and we get to do it deeply: native resource types, K8s-aware insights, remediation that understands controllers and rollouts. Focus is the whole advantage. A generalist can’t out-specialize a specialist without abandoning the generalism that made it valuable.
It also helps that we started open source, Apache 2.0, and lightweight — under 50 MB per node, no Prometheus, no databases to run. The fastest way to earn trust in infrastructure is to let people read the code and run it themselves.
What KubeBolt is not
Honesty includes saying where we don’t play:
- Not an APM. We won’t trace your application’s internal spans.
- Not a log platform. We won’t be your centralized logging backend.
- Not VM/serverless monitoring. If it’s not Kubernetes, it’s not us.
If you need those, keep your existing tools — KubeBolt is happy to live next to them. We’d rather be the best at one thing than mediocre at ten.
Who should use KubeBolt — and who shouldn’t
You probably should if you run real workloads on Kubernetes, you don’t have a dedicated SRE army, and you’re tired of tools that diagnose but never act.
You probably shouldn’t (yet) if your monitoring needs are mostly non-Kubernetes, or you’ve already invested heavily in a setup that operates — not just observes — your cluster.
That’s the whole thesis. The market is crowded with tools that watch Kubernetes. We built the one that runs it. If that resonates, the OSS agent installs in under two minutes — start there.