Xovris looks after everything your business runs – websites, apps, domains, email, code and security – the way a whole IT team would: it tells you the moment something breaks, works out why, fixes it with your permission and proves the fix with the same test that failed.
How private the check is
Your browser asks public DNS and the domain’s registry now; the certificate and page checks from Xovris’s probe switch on at launch. Nothing is saved to an account. Once the probe runs, it counts your free checks with a keyed hash of your IP address and of each website you check – never the readable address – kept for 25 hours, and keeps the result in memory for 60 seconds. Your browser remembers the last address you checked.
What the check keeps, and fair use: Privacy · Terms
Today that means OpenTelemetry for services in any language and signed webhooks for any tool that accepts them. Next, Xovris connects any other service through its own API, CLI or MCP server, asking your consent at each step and naming the mechanism it used. Every integration, its state and its permissions
Xovris connects it for you
You sign in and approve. Xovris writes the configuration, proves the first event arrived and moves each rung only on stored evidence. The command line is there if you prefer it.
Setup says done only when it has seen the evidence
Every connection climbs the same four rungs. A rung moves only when Xovris has read the evidence back from its own storage – an acknowledgement is never enough.
1
Connected
Your credentials were checked with the provider and the answer was read back.
2
Telemetry received
The first record – a check result or an event – is stored, not just accepted at the door.
3
Monitoring verified
A real event from your deployed app, or a full round of checks, is stored. A test event alone never counts.
4
Repair authorisedOptional
When you choose it: a write grant you read scope by scope, covering each zone or project you want Xovris to fix.
Pull request
Vercel
Coding agent
Command
Xovris opens the pull request Beta
From the first release, you install the Xovris GitHub App on one repository. Once you agree to the exact words below, Xovris reads the files its codemods need, commits the change to a new branch and opens a pull request whose description lists every change. Merging moves no rung – your first stored event does.
What you agree to, word for word
Xovris may read the files it needs from the repository you choose – package manifests and the files that start your app – and open one pull request on a new branch. Nothing is pushed to its default branch. No file is sent to an AI model.
Changed your mind? Closing the pull request deletes its branch, and Xovris reads the deletion back.
With the first release, Xovris opens this pull request through its GitHub App.
Alerts you have seen arrive before anything breaks
Alerts reach your own email from the first minute – one press on Alerts adds your verified address, nothing to set up. When you add Slack, a test alert shows Slack's own acceptance – and if a channel fails, Xovris says which and sends the alert by email instead.
npx xovris inita recorded run
┌Xovris – connect your app
◆Found Next.js, using npm.
◇Sign in
│Your browser opened to approve this sign-in.
│Check the browser shows the same code: FVVG-XSWG
◒Waiting for you to approve in the browser
✔Signed in to acme
◒Creating an ingestion key for this app
✔Created an ingestion-only key
◇4 changes in ~/acme-web
│install @xovris/next with npm – The Xovris layer over OpenTelemetry for this stack.
│create instrumentation.ts – Starts Xovris on the server and reports request errors (Next.js instrumentation hook).
│ + // Added by npx xovris init - remove with npx xovris remove
│ + export async function register() {
│ + if (process.env.NEXT_RUNTIME === 'nodejs') await import('@xovris/next/register');
│ + }
│ +
│ + export { onRequestError } from '@xovris/next';
│ + // Added by npx xovris init - remove with npx xovris remove
│ + import '@xovris/next/client';
│ +
│set XOVRIS_INGEST_URL, XOVRIS_INGEST_KEY, NEXT_PUBLIC_XOVRIS_INGEST_URL, NEXT_PUBLIC_XOVRIS_INGEST_KEY in .env.local – The ingest address and an ingestion-only key. The key can only send events.
✔Wrote 4 changes; each is listed in .xovris/manifest.json
◒Sending a labelled test event from this machine
✔The ingest edge accepted the test event
◒Waiting for Xovris to read the event back from storage
✔Telemetry received – stored 2026-10-01T19:20:09.213Z
◇Next
│Deploy this change. Monitoring is verified when the first real event from your deployed app is stored.
│Follow it live: https://acme.xovris.ai/
└Xovris is installed. Remove it any time with npx xovris remove.
What every fix gives you
What broke, what changed and the same test that failed, passing again – in a plain report you keep. Until that test passes, the issue stays open and you pay nothing for it.
You pay nothing for a fix until the test that failed passes. Until then the issue stays open and Xovris keeps working on it.
Recorded from the product itself on a test domain, example.com. No customer was involved.
Three things to know before you start
What will Xovris change on my systems?
Whatever you allow it to fix. Watching needs no access at all; each connection you grant extends what Xovris can fix, and every fix runs inside what you granted, as the exact change you approved, with its undo written down first.
Watching is free – 50 monitors, with no AI and no hidden model calls. Builder adds fixing: Xovris fixes and proves issues for US$39 a month, and an issue counts only once it is fixed and proven.
Join early access and Xovris starts on everything you run the day accounts open – it keeps checking, alerts you on the channel you choose and shows every fix as it is proven.