Questions, including the awkward ones

Does Kesvara diagnose the outage?

No. It suggests from history and does not diagnose. It shows an earlier incident that looks similar, the terms the two share, and the action item a person wrote when it was resolved. It never states a cause.

What does Kesvara do when nothing in my history is similar?

It says nothing is similar. A suggestion appears only when a stored prior incident clears one of two rules: a rank score of 0.05 and at least three distinct shared terms, or a rank score of 0.05 and one shared workspace vocabulary entry, written down by somebody on the team. Nothing else is shown, and a match made by a shared vocabulary entry is labelled as one on the card, naming the entry and the words that hit on each side. A new workspace sees no suggestions for weeks, which is correct rather than broken.

Can Kesvara show a match that does not exist?

No. Every match row must point at a stored prior incident by a non-null foreign key, and the page refuses to render a suggestion whose cited incident is not in the workspace. Matches come from full-text search over your own incidents, not from a model.

Where is a language model involved?

Only after search has already linked two incidents, and only to write one sentence about what the two records have in common. That sentence is checked outside the model call: any number or substantive word not present in the two records, any statement of cause, and any recommendation cause it to be dropped, and the match is shown with its shared terms and no prose.

Does Kesvara learn from my feedback?

No, and that is deliberate. Every suggestion asks whether it was the same failure, and the answer is stored with the name of whoever gave it and the date. Nothing reads it back into matching: no threshold moves, no result is re-ranked, and a suggestion somebody rejected is still found by the next search. Matching stays ordinary full-text search that a person can check by looking at it, rather than a rule that drifts for reasons nobody can reconstruct. A rejected suggestion does fold away on the card it was rejected on, so the next person does not have to read it again. The workspace page shows three counts — marked the same failure, marked not the same, and nobody judged — and never a percentage, because answering is optional and a rate over the people who chose to answer would read as an accuracy figure it is not.

My tool is posting and no incidents are appearing. How do I find out why?

The settings page lists the last 20 things Kesvara refused on the way in, with the reason, what the content-type said, the size, and the first few hundred bytes of the body. A payload with no readable alert text is refused rather than stored under a title like Untitled — a placeholder row becomes a future suggestion citing an incident that never happened — and before this the only sign was a POST counter going up with nothing behind it. No request header is recorded, because your webhook token arrives in one, and anything in the body shaped like a token is redacted. A POST with a token we do not recognise is answered and forgotten: there is no workspace to attribute it to, and guessing at one would let a stranger write onto your page.

Which timezone are the dates in?

Your workspace's. It defaults to UTC and anybody in the workspace can change it on the settings page; every time carries the zone it is in, and nothing stored changes — the database is UTC either way. This matters more than a display preference: a suggestion says similar to the incident on 5 May, and a team whose outage was at 09:00 on the 6th would go looking in their own chat log on the wrong day. Two things are deliberately not converted. A date you imported is printed exactly as you typed it, because a row from a spreadsheet is a calendar date with no hour behind it and converting it would move it by a day in New Zealand's summer. And the weekly digest is a UTC week, boundary and lines together, because that boundary is what stops it being sent twice — it says so in the message when your workspace is not on UTC.

Can I leave a workspace, or close my account?

Both, and they are different acts. Anybody can leave a workspace themselves — you are not waiting on an owner to remove you — after a screen that counts what you wrote. The one refusal is the last owner of a workspace: make somebody else an owner first, or close the workspace, because a workspace with nobody who can administer it cannot be fixed by us either. Closing your login is on your account page and is refused while you are in any workspace at all: the page names each one and what would clear it, rather than choosing on your behalf between stranding a team and deleting other people's history. Closing ends every session, removes your password and empties your address, and deliberately deletes nothing you wrote — the action items you typed stay in that team's library and stop naming you, reading somebody who has since closed their account. You can sign up again with the same address; it is a new account with nothing in it.

Does Kesvara close an incident when my alerting tool says it recovered?

Yes, under a strict rule. A resolved or OK notification is never stored as an alert. It is matched to an open incident by identical fingerprint, and the card closes only when every distinct check on it has cleared after its own last alert — one recovery does not close a six-alert storm card. A closed card has no action item, so it is not in the match library until someone writes one.

How do alerts get into Kesvara?

Two ways. Each workspace gets a webhook URL that accepts POSTs — Prometheus Alertmanager and Grafana work without adapting anything, and any JSON with a summary, title or message field is read. It also gets a forwarding email address, for tools that can only send mail. One Alertmanager POST carrying forty alerts becomes one incident card, by the same grouping rule.

On this deployment nothing is receiving mail at in.kesvara.deplyra.com: the endpoint exists and is tested, and no mail routing points at it, so a forwarded alert is discarded before Kesvara sees it. The webhook is the door that works today.

Does Kesvara tell me when an incident opens, or do I have to watch the dashboard?

A workspace can give Kesvara one destination URL — a Slack, Mattermost or Discord incoming webhook, or anything of your own that accepts a JSON POST — and one message is posted there when an incident opens. Only the alert that opens a card is announced: a storm of forty alerts is one card and one message. The message carries a citation only when the same search that fills the card returns one, and says so plainly when it does not. Delivery is three attempts over a few seconds with no queue behind it, so a message can be lost if your endpoint is down; the incident card is unaffected.

How do I know a message really came from Kesvara and not someone else who found my webhook URL?

Every message carries an HMAC-SHA256 of its body and a signed timestamp, under a key shown on your workspace settings page. Your receiver recomputes it over the raw request body and compares. Two honest limits: Slack, Discord and Mattermost ignore those headers entirely — for them the secrecy of the destination URL is the only protection, which is the model they are built on — and the signature protects nothing unless your own receiver checks it and rejects the message when it does not match. That is code at your end. We cannot write it for you and we cannot tell whether you have.

Will Kesvara page me?

No. It has no schedules, no escalation, no phone calls and no SMS. It posts one message to one URL you configure, and whether that wakes anyone depends entirely on the tool at the other end. Paging is what the tool upstream of Kesvara already does.

What does Kesvara cost?

Nothing today. There is no card form and no paid plan. There is a waitlist.

Was this called Sentinel?

Yes, until 5 August 2026. It is now Kesvara. Microsoft Sentinel is a security-operations product from Microsoft sold to the same buyer, and a name that has to be disambiguated in the footer of every page is a name that costs something on every page. sentinel.deplyra.com redirects here permanently, so nothing already linked breaks. Kesvara is unrelated to Microsoft Sentinel.

Kesvara put an alert on the wrong incident card. Can I fix it?

Yes, and it is one of the few places this product lets you overrule it. Grouping is a rule rather than a judgement, so it is sometimes wrong: any alert except the one a card was opened by can be moved onto an incident of its own, by anybody in the workspace, after a screen saying what that costs. The new incident is dated when the alert arrived rather than when you moved it, both cards say afterwards that it happened, and the alert keeps Kesvara's own reason for grouping it where it was. Three limits, all of them on that screen: it does not change the rule, so the next alert like it groups the same way; it does not recompute a suggestion already shown on either card; and there is no merge, so two cards that should have been one cannot be joined.

We typed something into an action item that should not be in your database. Can we take it out?

Yes, by withdrawing the line rather than correcting it. A correction deliberately keeps the previous version and shows it on the card, because every citation here claims those words are what your team wrote at the time — so correcting a customer's name out of an action item leaves it on the page twice. A withdrawal deletes the sentence, every earlier version of it, and the citation on every card that had one; an owner does it, and what remains is a record that a line was withdrawn, by whom and when, with no copy of the text. Two things it cannot do: there is no undo, because nothing here holds the words afterwards, and it cannot reach a notification already delivered to your chat tool.

What data does Kesvara hold?

The alert emails you forward, stored as they arrived, plus the incidents and action items you write. It has no access to your infrastructure, your telemetry or your source code, and there is no shared corpus across customers.