The repeat server alerts that cost sleep and uptime
Fixed the same incident before? Virca runs the fix next time.
Virca is AgenticOps for Linux servers, on cloud VMs or bare metal. It serves one engineer or small team running production. It handles repeat alerts: full disks, stopped services, failed checks. The Virca Process, a process that runs on each server, checks the alert. It runs a team-approved fix, then re-checks its target. New issues go to your team.
Fixes your team already knowsRestartsFull disksRunaway processesMemory leaksOld logsFlaky health checks
Monitoring built in. Ready-made fixes to start from.
Who does what
Your engineer tells it. AI sets it up.The Process runs it.
Two of the four are human, and they are the two where anything is decided.
A person decidesSoftware does the work
At 2:14am
Nobody is woken for this.
The fix for tonight's alert already exists — it is in someone's head, and it has never had a way to run without them. This is that way.
That doesn't mean nobody decided — the deciding happened in daylight, on a screen showing the exact commands and the exact servers, and you choose whether the actions that carry real risk wait for one more OK before they run.
One service on each server, one connection out, no inbound port.
The Process that raises the event is the Process that runs the fix.
- 01Validatestill above threshold after 60sreal
- 02Investigatejava pid 4121 · memory climbingfindings
- 03Actservice_restart · approved setran
- 04Confirm/health 200 · memory back downheld
Memory leak on app-server-02. Service process restarted, confirmed answering again. No one woke up.
Illustrative example
Who it's for
You've fixed it before. Now it runs without you.
- Running the system aloneYou're the only one on call.Virca takes the problems you've already solved, so only new problems reach you.
- Every alert comes to one phone.
- A weekend with no one to hand off to.
- Many servers, a few peopleThe alerts come from every server.Approve a fix once, and the fix runs on every server you assign.
- Whoever knows the fix gets the alert, even on a day off.
- The same fix, typed on server after server.
First · Nights and weekends
It starts with the hours nobody wants.
One illustrative week of alerts, Tuesday to Monday. Most closed with no one called, the weekend from Friday 11pm to Monday 8am ran on the same approved actions, and two went to the team with the facts attached.How most nights close on their own →What it changes
For the person who owns the headcount
The servers grow. The team doesn't have to.
It runs next to the monitoring and alerting you already have. Nothing to migrate, nothing switched off.
How it works
Four steps, one run, on the server that raised it.
- 01 · ValidateIs it real?Most alerts are noise. They close here.Most close here
- 02 · InvestigateWhat happened?The facts around the event, gathered on the server while it is still happening.Findings kept for the morning
- 03 · ActThe approved fixInside the set your team approved. Only when one fits.No fit: goes to your team
- 04 · ConfirmDid it hold?Re-checks its own target, and calls the rollback steps if not.Held, or rollback called
Every run goes on the record.
After the install
Install the Process. Then set it up from your own AI.
Connect the AI client you already use over MCP. It reads what the Process sees and drafts ActionBooks with you. Your team reviews each one and turns it on.
Ask
“What keeps firing on the web servers?”
It reads the servers, the alert history and the incidents that followed.
Draft
“Write an ActionBook for the full-disk alert.”
It reads the language and the fixes installed in your workspace, and writes a draft to review.
Connect
“Which rule should call it?”
It reads your event rules, the templates and what is firing now.
Start here
Six things worth knowing. One page each.
The argument, the mechanism and the caveats.
- 01 · The problemThe 2am taxWhat the night costs, and who it keeps landing on.The full cost, line by line →
- 02 · Why nowSystems built with AI, run by the same few peopleWhat changed, what just became possible, and what stays with your team.Why this is possible now →
- 03 · How it worksNights back, and fixes the company keepsWhat it takes off your team, who draws the line, and how it runs alongside your tools.Walk the mechanism →
- 04 · Versus what you haveThe same fix, four roads to the serverWho wrote the action, whose data it runs on, how much sits in between.See the comparison →
- 05 · Your questionsThe questions asked before trusting itThe awkward ones included. Where the honest answer is “not yet,” it says so.Read the answers →
- 06 · Who it's forOne person on call, or a few people with many serversWhat Virca takes off each, and the page written for each.See both →
Tonight's alert is one your team has answered before.
Write it down once, approve it in daylight, and let the Process work at night. We are also taking a small number of design partners — our engineers in the room for your first ActionBooks, and a direct line for everything you find wrong.
See how it works →