How Kesvara differs from the tools you already have
Kesvara does one narrow thing. Most of this page is about what the other tools do better, because that is the part you need in order to decide, and a comparison you can falsify in one click costs more trust than it buys.
The one thing Kesvara does
It searches your own resolved incidents for one that looks like the incident in front of you, and shows the action item a person wrote at the time, with the date. That is the product.
What each of these does that Kesvara does not
PagerDuty
Detects, escalates and wakes people up — on-call schedules, overrides, phone calls that keep ringing, escalation policies. Kesvara does none of that and is not trying to: it sits downstream of whatever pages you. PagerDuty also has its own alert grouping, which for many teams is already enough.
Datadog / Grafana / New Relic
They hold the telemetry. Metrics, traces, logs, dashboards, the ability to answer "what was the p99 at 03:14". Kesvara has none of your telemetry and never asks for it — it sees the alert emails you forward and nothing else. If you want to know what actually happened, you go to them, not here.
incident.io / FireHydrant / Rootly
Full incident management: Slack-native declaration, roles, comms templates, status pages, stakeholder updates, retrospectives, and analytics across incidents. They are considerably larger products, they integrate with the tools you already run, and several of them also surface similar past incidents. If you are buying an incident platform, buy one of those.
A wiki of runbooks
A good runbook wiki is better than Kesvara whenever a runbook exists, because a runbook is written deliberately, edited, and covers what to do rather than what someone once did. Kesvara's advantage is only that it is populated as a side effect of closing incidents — the wiki page that nobody wrote is the one it can still show you.
Where Kesvara is genuinely weaker
- It is useless when new. The library is your own history. With no resolved incidents there is nothing to match against, and it will say so, for weeks.
- Lexical matching, not semantic. Two incidents described in entirely different words are not linked on their own. A team that writes "connection pool exhausted" one month and "DB maxed out" the next would see a miss where a person sees a match — so you can teach it your words: a named entry holding the terms your team uses for one failure. That is a dictionary somebody types, not a model, and every match it makes names the entry and shows the words that hit on each side.
-
It does not do semantic search, and that was a decision with a
number on it. Matching on meaning with embeddings was measured
against this product's bar before being built, and missed: roughly half
of what it would have shown was a citation to an unrelated outage, and
the two highest-scoring pairs in the test corpus were both wrong. "Disk
space low" scored higher against "disk space recovered" than any genuine
pair did. So did "payments checkout failing" against "card payments
declining" — two true descriptions of one visible symptom with two
different causes and two different fixes. No threshold separates those,
because their similarity is real; what differs is the cause, and this
product does not claim causes. It was not built. The measurement is
scripts/calibrate_semantic.py. - Two intake doors, one way out, and no integrations. A webhook URL and a forwarding email address in; one outgoing message per new incident, to one URL you paste in yourself. No Slack app, no PagerDuty integration, no two-way sync, no OAuth into anything — Kesvara reads what you send it and posts to the one address you gave it, and it never reaches into your systems. Nothing is being received at the forwarding address on this deployment yet, so today the webhook is the door that works.
- No paging, no schedules, no status page, no analytics. The outgoing message is one POST to one URL. Whether it wakes anybody is decided entirely by the tool at the other end, and there is nothing here that escalates, retries for minutes, or phones a second person.
- Nobody has run it at scale. It is new. The grouping windows are reasoned choices, not numbers tuned against a year of a large team's alert volume.
When Kesvara is worth having
A small team, alerts already arriving by email, a habit of writing one line about what fixed something, and the specific recurring feeling of "we have seen this before and I cannot remember what we did". It is cheap to try because it needs no access to anything: you forward mail to an address.
No number on this page is a benchmark and none of these products was tested against Kesvara. This is a description of scope, written from each product's own public documentation. Where you find it wrong, it is wrong and we would like to know.