For on-call teams
An AI first responder for your on-call, scored on your own past incidents before you commit.
For software teams with a small on-call rotation. When an alert fires, it reads your logs, metrics and recent deploys and posts the likely cause and a suggested fix, linked to the evidence. It runs in your own cloud account or Kubernetes cluster, with your own AI model key. It has read-only access: our system can't change anything on its own. Every fix is a suggestion your engineer reviews and runs.
In development: The pilot version is being built now. No client runs it yet. Earliest pilot start date confirmed in writing.
The problem
The slow part is finding the cause.
When an alert fires at night, someone on a small rotation wakes up and starts reading: logs, dashboards, recent deploys, what changed. Most of the time goes into finding the cause, not fixing it. The same few engineers carry that load, week after week.
This assistant does the first reading for them. It collects the evidence, names the likely cause and suggests a fix, so the engineer starts from an evidence-linked summary instead of a blank screen.
The Replay Check
Tested on your past incidents first.
A small paid check, with its fee fixed in writing and credited against a pilot if you go ahead within 60 days. You see how it would have done on your own history before any pilot price.
- What it takes from you: 10–30 of your past incidents, exported with only what was known when each alert fired (the alert, and the logs, metrics and changes from that time), and about 1–2 hours of one engineer. No other access, and nothing that can change your systems.
- For scoring, you tell me in a line or two what really caused each incident and what fixed it. That answer is kept apart and is never an input: the system's answers are saved and frozen before yours are opened.
- Each incident is run three times. It counts as right only if all three runs are right, so one lucky answer can't inflate the score.
- You get, per incident, what it would have said next to what really happened, and what it got wrong and why. Plus totals: how often it was right, how often it said “not sure”, a simple rules-only baseline to compare against, an error range (with this few incidents the margin is wide), and the AI cost per incident.
- Then an honest verdict: is a pilot worth it for your team, yes or no. Your copies are deleted afterwards, with a written certificate.
How the watch-only pilot is designed to work
It watches and suggests. Your engineer decides.
The pilot is a paid, fixed-length phase on your live alerts. It only watches and suggests, and the numbers it must reach are set in writing from your Replay Check.
- An alert fires in your monitoring or incident tool.
- The system reads logs, metrics and recent deploys, with read-only access.
- Passwords, keys and personal details it detects are masked before the AI model sees anything.
- The AI model names the likely cause and one suggested fix, linked to the evidence it is based on.
- A fixed list of allowed fix types, agreed with you in advance, is checked by plain code, not the AI.
- The diagnosis and the suggestion are posted for your engineer, who decides and runs any fix.
- Every step is written to an audit log in your account.
Reads, never writes
It reads alerts, and logs, metrics and recent deploys and changes, through read-only credentials. It is designed to check those credentials before it starts and to refuse to start if it finds write access. Where a tool offers no way to check a key, you confirm its access in writing first.
Earns each step
For the first weeks it only watches: each diagnosis is posted marked “not checked, do not run”, and your on-call lead marks it right or wrong. Only fix types that meet numbers agreed with you in writing move on to a posted suggested fix, which your engineer decides on and runs.
Shows its evidence
Each diagnosis links to the log lines, metrics and deploys it is based on, so your engineer can check it quickly. It suggests one specific fix, for example a restart or a rollback.
Says when it isn't sure
It is built to post “not sure, a person should look”, with what it checked, instead of guessing. It can still be wrong, which is why your engineer checks every suggestion.
Posts where you work
Slack first. Microsoft Teams and email are planned.
Stays out of your paging
It is never part of your paging path. If it stops, it simply stops posting, and your normal alerting and on-call keep working as today.
Where it runs
Designed to run in your own environment.
It is designed to run inside your own environment: a Kubernetes cluster, a single VM, or your cloud account (AWS, Azure or Google Cloud). The first supported sources are Prometheus and Alertmanager, Kubernetes, and AWS; others on request. It uses your own AI model account and key, with a spending limit you set.
It is a system delivered into your account, not a hosted service: nothing depends on Hadavin's servers. It is designed to write only to the one chat channel you name and to its own records in your account, and to send outbound traffic only to an allow-list: your tools, the AI model and your chat tool. After the final payment the code is yours, in your repository.
Safety and data
The short version of the security pack.
The full security and data pack, with data tables and answers to common security questions, is sent before any Replay Check. Ask for it at sales@hadavin.com.
- It has read-only access. Our system can't change anything on its own, and Hadavin holds no credential that can change your systems.
- Passwords, keys and personal details it detects are masked before anything is sent to the AI model. The original passwords and keys are never stored, so they can't reappear in what it posts.
- Text from your logs is marked as data, not instructions, and checked for hidden instructions. Because it has no tool that can change anything, a trick hidden in a log can at worst produce a wrong suggestion, which your engineer sees before anything runs.
- Your data is never used to train or tune an AI model, and the system uses your own model account and key.
- Every step is written to an audit log in your account. You can remove its access at any time by deleting the read-only role or revoking the keys you gave it.
- A mutual NDA before you share anything, and a data processing agreement when personal data is involved (almost always the case for incident logs).
- Hadavin is a one-person studio. Not SOC 2 audited yet; no third-party penetration test yet. I answer your security questionnaire in writing.
- Professional indemnity and cyber insurance are being arranged and are not yet in force. A pilot connects to your live systems only after they are, and you see the certificates first.
Honest status
Where it stands today.
The pilot version is in development. It reuses tested parts of an earlier demo incident responder, which has run only in Hadavin's own test environments. Your pilot would be the first time it runs in a company's own account. Replay Checks and first pilots start once it is ready: the earliest pilot start date is confirmed in writing. A pilot connects to your live systems only after our insurance is in force.
The AI can be wrong. That is why the first pilot only watches and suggests, why every diagnosis links to its evidence, and why it is measured on your own past incidents before you decide. This page shows no client logos, case studies or testimonials, because there are none yet. That's why the Replay Check exists: you judge it on results from your own incidents, not on our word.
Hadavin is a one-person studio: the engineer you talk to is the one who builds and runs your pilot, based in India with calls in your time zone. Who builds it.
Ask for a Replay Check.
Tell me your incident tool, where your logs and metrics live, and roughly how many incidents you get a month. I reply within one working day with a few questions and call times in your time zone.