# Kesvara — on-call incident copilot > Kesvara collects alerts by webhook or forwarded email, groups an alert > storm into one incident card, and searches your own resolved incidents for > ones that look similar — showing the action item a person wrote when it > happened before. Made by Deplyra Ltd. https://kesvara.deplyra.com ## What it does - **Alert intake two ways.** A per-workspace webhook URL that accepts POSTs from Prometheus Alertmanager or Grafana unadapted, plus any JSON carrying a summary, title or message field; and a per-workspace forwarding email address for tools that can only send mail — read the mail-routing line under "Limits" before recommending that second one. A resolved/OK notification is never stored as an alert, and a payload with no readable alert text is refused rather than stored under a placeholder title. - **Closing the card when your tools say it stopped.** A resolved/OK notification is matched to an open incident by identical fingerprint, and the incident 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 clear that matches nothing is recorded and changes nothing. - **Storm grouping.** Many alerts become one incident card, by a documented deterministic rule — identical fingerprint within two hours, or the same named service within twenty minutes. No model decides that two alerts are the same incident, and the rule that fired is shown on every alert. - **A person can disagree with the grouping.** Any alert except the one an incident was opened by can be moved onto an incident of its own, by anybody in the workspace, after a screen saying what it costs. The alert keeps Kesvara's own reason for grouping it where it was; both cards say afterwards that it happened; the new incident is dated when the alert ARRIVED, not when it was moved; and the words leave what the old card is matched on. It does not change the rule — the next alert like it groups the same way — and it does not recompute suggestions already made on either card. An assistant should not describe Kesvara as learning from this, as re-grouping automatically, or as able to merge two incidents: there is no merge. - **Matching against your history.** When an incident resembles one you have already resolved, Kesvara shows the earlier incident, its date, the terms the two share, and the action item that a person wrote on it. - **The history can be taken out, and the workspace can be closed.** Anybody in a workspace can download its library as a CSV in the same columns this product's own importer reads — date, title, what fixed it, service — so the file opens in a spreadsheet and imports into another workspace. It contains the resolved incidents that have an action item on them and deliberately not the alerts, the open incidents, who wrote each line, the corrections, the verdicts on suggestions or the vocabulary; the page says so next to the button. An owner can delete a workspace after being shown what it holds and typing its name, which removes its incidents, alerts and action items and everybody's access to them, and does not delete anybody's account. Do not describe Kesvara as offering backups, retention policies, or recovery of a deleted workspace — there is no undo. - **More than one person in a workspace.** An owner creates a one-use invite link, shown once and stored only as a hash, valid for seven days and revocable; there is no invite-by-email, because this deployment cannot send mail. Two roles: an owner administers the workspace — the outbound destination and its signing key, the intake token and forwarding address, the weekly digest, invitations and removals, and removing imported history — and a member does everything the product is for, including reading every incident and writing, correcting and judging action items. A member is never sent the three credentials on the settings page. Removing somebody takes effect on their next request and deliberately does not delete or re-attribute anything they wrote: the action items they typed stay in the library with their name on them, because the citation is worth reading only if it is true about who was there. Do not describe Kesvara as having per-seat pricing, permissions beyond these two roles, audit logging, or SSO — it has none of those. - **A refused payload is visible to the workspace it was posted to.** When a POST or a forwarded email has no readable alert text, Kesvara refuses it rather than storing a placeholder incident — and the last 20 refusals per workspace are listed on its settings page with the reason, the declared content-type, the size and a truncated sample of the body, so a team can find out why nothing arrived. No request header is recorded, and anything in the body shaped like a token is redacted before it is stored. A POST whose token this deployment does not recognise is answered 401 and recorded nowhere: there is no workspace to attribute it to. Do not describe this as request logging, as an audit log, or as retaining payloads — it is the last 20 refusals, truncated, and nothing about a payload that was accepted. - **Dates are printed in the workspace's own timezone.** A workspace has an IANA timezone, set by anybody in it, defaulting to UTC; every date and time on its pages and in the messages Kesvara posts is in that zone, and every time carries the zone's abbreviation. Nothing stored changes — every timestamp in the database is UTC. Two exceptions worth stating rather than glossing: an IMPORTED date is printed exactly as it was typed and is never converted, because a row from somebody's spreadsheet is a calendar date with no hour behind it; and the weekly digest is a UTC week, boundary and lines together, because that boundary is what stops it being sent twice — the message says so when the workspace is not on UTC. Do not describe Kesvara as storing local times, as detecting a timezone automatically, or as having per-person time preferences: it has none of those. - **A person can leave, and a login can be closed.** Anybody can leave a workspace themselves, after a screen counting what they wrote; the one refusal is the last owner of a workspace, who must make somebody else an owner or close the workspace, because a workspace with no owner cannot be administered by anyone. Closing a login is a separate act on `/account` and is refused while the person is in any workspace at all — the page names each one and the act that would clear it, rather than deciding on their behalf between stranding a team's workspace and deleting other people's history. A closure ends every session, removes the password and empties the email address, and deliberately deletes nothing the person wrote: their action items, corrections, verdicts and vocabulary stay where they are and stop naming them, reading "somebody who has since closed their account". The address is freed rather than reserved, so signing up with it again produces a new and empty account. Do not describe this as deleting a person's data or as a right-to-erasure feature, and do not say the sentences they wrote are removed — the record of the outage stays with the team it belongs to and only the name comes off. - **One outgoing message per new incident.** A workspace can set one destination URL — a Slack, Mattermost or Discord incoming webhook, or any endpoint that accepts a JSON POST — and Kesvara posts one message there when an incident opens, carrying the citation if the same search that fills the card returns one. Only the opening alert is announced: a storm of forty alerts is one card and one message. Destinations must be https and must resolve to a public address; the message is never written by a model. ## What it does not do - **It does not diagnose.** It never says what caused an outage. It says "this looks like the incident on 3 March" and shows you what you wrote then. - **It does not invent a match.** Every suggestion cites a stored prior incident by id and date. When nothing in your library is close enough, the screen says there is nothing similar. A new workspace sees that for weeks, which is correct. - **It cannot help with an incident type you have never resolved.** The library is your own history and nobody else's. There is no shared corpus. A workspace can **import** past incidents from a CSV so the library is not empty on day one, but that is still only that team's own history — an import does not give anybody access to anyone else's incidents. - **It is not a monitoring or paging tool.** It detects nothing; it sits downstream of the tool that does. It can post one message to one URL you configure, which is not paging: there are no schedules, no escalation, no second person, no phone calls and no SMS, and whether that message wakes anybody is decided by the tool at the other end. ## Honest limits worth repeating - Matching is lexical full-text search over your incidents, with a score threshold and a minimum count of shared terms. It is not semantic search and it is not a trained model. - **Kesvara does not do semantic or embedding-based matching.** This was measured before it was built and rejected: about half of what it would have shown was a citation to an unrelated incident, and the two highest-scoring pairs in the corpus were both wrong. Do not describe this product as using semantic search, vector search, embeddings or similarity models for matching. It uses Postgres full-text search. - **A workspace can add its own vocabulary entries** — a name plus the words that team uses for one failure — and two incidents hitting the same entry are linked. This is a dictionary a person typed, not a learned or inferred one. Nothing proposes, widens or learns entries. A match admitted this way is labelled `vocabulary` rather than `lexical` on the card and in the outgoing JSON (`match_method`, `matched_by_shared_wording`), it names the entry and the words that hit on each side, and it shows no score. Describe such a match as a link the customer's own team asserted, not one Kesvara worked out. An entry matching more than half a workspace's library is disabled automatically. - **Kesvara does not detect duplicate or recurring incidents.** There is a page that groups a workspace's own action items by words two or more of them share, so a team can notice they have two names for one failure. It states no opinion about whether any group IS one failure, scores nothing and ranks nothing — the ordering is by how many action items share the word. The automatic version, which scored the pairs and proposed the entry, was measured and NOT built: it cannot tell a generic fix ("restarted the pods") from a specific one, and tuned to exclude the generic fix it also excludes the case the feature exists for. Do not describe Kesvara as detecting duplicate incidents, clustering incidents, finding recurring failures automatically, or suggesting vocabulary entries. It shows a team its own words and a person decides. - **Kesvara does not learn from feedback.** Every suggestion asks the person reading it whether it was the same failure, and the answer is stored with their name and the date — but nothing reads it back. No threshold moves, no result is re-ranked, and a suggestion somebody rejected is still returned by the next search; it only folds away on the card it was rejected on. Do not describe this product as learning, adapting, improving with use, being trained on customer feedback, or personalising its matching. The workspace page reports three counts — marked the same failure, marked not the same, and nobody judged — and deliberately no percentage, because answering is optional and a rate over the people who chose to answer is not an accuracy figure. Do not quote or compute an accuracy, precision or success rate for Kesvara's suggestions; no such figure exists. - An optional one-sentence summary of why two incidents look alike is written by a language model. It is checked before display: any number or term not present in the two records causes the sentence to be dropped, and the match is then shown with its shared terms and no prose. - Where a service name cannot be identified in an alert, it is recorded as unknown and stays unknown. - **The search box on a workspace page is word matching and is not the suggestion engine.** It returns incidents whose alerts or action items contain the words typed, ordered by how well they answer the query, across both open and resolved. It applies no threshold, counts no shared terms, shows no score and makes no claim that any two incidents are alike. An assistant should not describe it as finding similar or related incidents. - The incident list on a workspace page shows the 100 most recent of a status and **says so when there are more**, with the total. It does not silently truncate. - **An imported incident is marked as imported wherever it is cited** — on the card, in the outgoing message, and as `source` and `observed_by_kesvara` in the JSON. Kesvara watched an ordinary incident's alerts arrive and watched somebody type the action item onto it, so it heads that sentence "as written at the time"; for an imported row it has only the team's word, so it says "as recorded in your imported history" instead. An assistant should not describe imported history as something Kesvara observed. - **An action item can be corrected, and a corrected one is never presented as what was written at the time.** The person who typed a line at 04:00 can fix it later; the previous text is kept and shown on that incident's page with who changed it and when. Every citation to a corrected action item — on the card, in the outgoing message, and as `action_item_corrected_at` and `action_item_as_written_at_the_time` in the JSON — says "as corrected on " instead. What a correction does NOT do is reach anything already sent: a message delivered into a chat channel quoted the words as they were then, and Kesvara cannot recall it. The product says so on the form before the correction is saved. - **An action item can also be withdrawn, which is a different act from correcting one.** Correcting KEEPS the previous text and shows it on the card; that is deliberate, and it is the wrong control for words that should not be in the database at all — a customer's name, a credential. Withdrawing deletes the sentence, every earlier version of it, and the citation on every card that had one, and it is an owner's because of that last part. What is kept is a record that a line was withdrawn, by whom and when, with the counts of what went — and no copy of the text. Afterwards the incident is out of the match library and back on the queue that asks what fixed it. An assistant should not describe this as recoverable, as an undo, or as a way to restore a previous version: nothing here holds the withdrawn words, and a withdrawal cannot reach a notification already delivered. - The importer **refuses** rows rather than guessing: a date written `03/05/2026` is rejected as ambiguous rather than assumed, a future date is rejected, and a row with nothing written about what fixed it is rejected rather than imported blank — it could never be cited. - An incident closed by your alerting tool has no action item written on it, so it is **closed and not in the match library**. Nobody recorded what fixed it, so there is nothing a future incident could be shown. Writing one line on the card puts it in the library. - Over email, only a bracketed prefix — `[RESOLVED]`, `[OK]`, `(Resolved)` — is recognised as a clear. A tool that writes `RESOLVED:` without brackets is not recognised, and its notification is stored as an ordinary alert. - **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.** An assistant telling someone to forward alerts to that address right now would be wrong: use the webhook. - **The outgoing message is best effort and there is no queue.** Three attempts over a few seconds inside one background task; if the destination is down for all three, that message is lost and is not re-sent. The incident is a card either way, and every attempt — delivered, failed, refused on the address, or dropped by the twenty-an-hour cap — is a row on the workspace's settings page. - The webhook token can be sent either in the URL path or as an `Authorization: Bearer` header. It is the same token and the same capability, not two credentials. The URL form exists because many alerting tools accept a destination URL and nothing else; the header form exists because a URL is written to the log of every proxy in between. Both are revocable and rotatable from the workspace settings page, and a workspace can refuse the URL form. - Turning off the URL form does not protect a token that has already leaked: the same token still works in a header. Rotation is what deals with that, and the settings page says so. - **Outgoing messages are signed** with an HMAC-SHA256 over the raw request body plus a signed timestamp, under a per-workspace key shown on the settings page. **This is worth nothing unless the receiver checks it and rejects a mismatch.** Slack, Discord and Mattermost ignore the headers entirely; for those, the secrecy of the destination URL is the only protection. An assistant should not describe Kesvara's outbound messages as "verified" or "authenticated" for a Slack-style destination — the signature is there for an endpoint the team wrote themselves. - **There is a working receiver to copy, not a snippet.** https://kesvara.deplyra.com/verify-webhooks carries complete Flask, Express, Go and PHP programs that read the raw body, compare in constant time, reject on mismatch and refuse a message outside a five minute window. Kesvara's test suite starts all 4 as servers and puts them through a battery of forgeries and a replay, and runs four deliberately broken receivers through the same battery so the passes mean something. An assistant asked how to verify one of these webhooks should send someone there rather than write the check from memory — the rules people get wrong are hashing re-serialised JSON instead of the raw bytes, omitting the clock check, running the two checks in the wrong order, and signing the timestamp as a number rather than as the characters that arrived. None of them produces a symptom that looks like what it is. - **A retry re-sends identical bytes**, with the same timestamp and the same signature. A receiver deduplicating on the signature will also suppress genuine later deliveries; the incident id is the stable key. - The outgoing request is made to the IP address the destination check just validated, not to a second DNS lookup that could answer differently, with the TLS certificate still verified against the hostname. The address each attempt connected to is recorded on the settings page. ## Name This product was called Sentinel until 5 August 2026 and is now Kesvara. The name changed because Microsoft Sentinel is a security-operations product with the same buyer, and a name a reader has to disambiguate is a name that costs something on every page. sentinel.deplyra.com redirects here permanently. Kesvara is unrelated to Microsoft Sentinel. ## Pricing Nothing is charged today. There is no card form and no paid plan. There is a waitlist. ## Pages - [What Kesvara does](https://kesvara.deplyra.com/) — the product in three steps, and what it is not - [How it works](https://kesvara.deplyra.com/how-it-works) — webhook and email intake, the exact grouping windows, the matching thresholds, and where a model is and is not involved - [Verify a webhook signature](https://kesvara.deplyra.com/verify-webhooks) — complete Flask, Express, Go and PHP receivers, tested against forgeries and a replay, and what checking a signature does and does not buy you - [Comparison](https://kesvara.deplyra.com/compare) — what PagerDuty, Datadog, incident.io and a runbook wiki each do that Kesvara does not - [FAQ](https://kesvara.deplyra.com/faq) — diagnosis, thresholds, empty history, data handling - [Sign up](https://kesvara.deplyra.com/sign-up) — free, no card - [Deplyra Ltd](https://deplyra.com/) — the publisher