How it works · Step 1 of 4
For the person carrying the pager
Validate: is the alert real, or is it something you can close?
A threshold crossing is not a problem yet. Deciding which it is has always been the first thing a person does at 2am — and on most nights it is also the last.
The problem
For the person carrying the pager
Most pages don’t need a fix. They need someone to look.
CPU is at 94% — the nightly report is running, as it does every night. Disk is at 91% — a log rotated late. The endpoint failed a check once and answered on the retry. Every on-call engineer knows this shape: you wake up, you look for four minutes, you go back to bed. Nothing was wrong, and it cost a night.
Nobody brags about automating this part. It is still the most valuable part to automate, because it is the part that happens most.
What Virca does
For the engineer who has to approve it
It looks before it does anything else.
When an event fires, the ActionBook bound to it — commands your engineer named, in an order AI wrote, approved by your team — does not start by changing anything. It runs read-only checks on the host. Is the process holding the load the one we expect? Has the condition persisted, or was it a spike? Is the thing the alert is about even the thing that is failing?
The checking happens on the host, in the Agent — not in a model somewhere else.
It closes as noise
The condition is explained or already gone. The event is recorded with what was checked and why it closed. Nobody is called.
It is real, and needs context
The check passes and the pass moves on to Investigate, gathering what the alert left out before anything is changed.
It is real, and unclear
The checks disagree, or nobody approved an action for this. It stops, tells your team what it found, and waits.
Virca is not cleverer than your engineer at this. It does the same look, in seconds, at 2:14am, without waking anyone — and it writes down what it saw either way.
What this is not
For whoever picks the tools