Skip to content
VIRCA
Sign inExplore the demoDemoPut your first fix to work →

Why it matters

A known problem still needs someone to answer it.

Your team already knows the fix. The service still waits until someone logs in to type it. You can count what that wait costs.

Illustration: the fix lives with your team, in a shell history and in a chat thread.

2:30 AM

At 2:30 AM, the fix might be one command.

Your team already knows it. Someone still opens a laptop and types it by hand. The rotation decides who answers. Until someone answers, the service keeps failing for its users.

What standby actually asks of a person

Being on call is standby duty. The phone stays loud. The laptop goes where you go. You stay near signal. A week of that is a week spent standing by for an alert that may not come.

Your team knows the fix.

Someone checks first, so the fix waits.

Illustration: an alert rings on server web-01 on Monday at 10:12, on web-03 on Tuesday at 02:30 and on web-02 on Tuesday at 16:40. Each time, someone opens a laptop and types the fix again.

What it costs

Count the cost with your own numbers.

It takes four steps and last quarter’s outages.

The fix worked. It is still only in someone's shell history.

Your team knew what to do. The fix stayed in a shell history and a chat thread, where it cannot run on its own. So the tenth memory leak costs a person as much as the first one did.

A written procedure still needs a person to read it and type what it says.

1Outages

Last quarter’s outages

Take the outages that ended in a fix your team had typed before.

2Checks

The ones a check catches

Keep the ones a server, process, URL or port check would catch.

3Minutes

Minutes waiting

For each one, count the minutes from the alert until someone started the fix.

4Your cost

What an hour down costs you

Multiply by what an hour down costs you. Set that next to $20 per server per month for the servers those services run on.

Why AI needs your team · 1

AI already works in development. In operations, a person usually still applies the fix.

Each team's server fixes mostly stay inside the team, so AI has had few fixes to learn from.

Illustration: two sides. In development, an engineer at a laptop and AI work from written-down code: main.tf, Dockerfile and deploy.yaml. In operations, an on-call engineer faces a server with an alert, and the fix lives in a shell history and chat threads.

In development

main.tfDockerfiledeploy.yamlci.yml

Infrastructure code is written down, often in public. AI has seen the same patterns again and again, so it writes this code well.

In operations

Shell historyChat threadsA private wiki page

The fix for a 2:30 AM incident is rarely written down in public. It names your servers, your paths and your services. A public example rarely matches it.

Why AI needs your team · 2

A command on a server is hard to undo.

AI is hard to predict. It can choose well once and differently the next time.

Illustration: two sides. AI in code: AI’s change goes to an engineer for review, and a revert brings it back. AI alone, on a live server: AI’s command, marked with a warning, goes straight to the server, and the way back is unclear.

AI in code

DraftReviewMergeRevert

A person reads the diff. Tests usually run before it ships. One revert undoes a bad change.

AI alone, on a live server

AI’s commandWritten at incident timeNo code review

The command often runs as written. Often there is no clean way back. One wrong command can turn an alert into an outage. That is why your team approves the fix first.

One week of alerts

Five alerts needed a terminal. With Virca, one did.

One illustrative week of alerts, shown twice. Four have a fix your team already knows. With Virca, the four with an approved fix close with that fix. Only the new one needs a terminal.

One illustrative week of five alerts, shown on two phones. Today all five need someone at a terminal, two of them at night. With Virca, the four alerts with an approved fix close with that fix. Only the new one needs a terminal.
One week of alerts, today and with Virca.

Before and after

What changes with Virca.

AI drafts the fix before an incident. Your team approves the fix and the servers it runs on. Virca runs it on the server, then re‑checks its target.

Compared onTodayWith Virca
Who looks firstTodaySomeone on the team, called by the alertWith VircaVirca checks the server first when a fix covers the alert. If the problem has already cleared, Virca stops there, and no one is called.
Who runs the fixTodayUsually whoever is on call types itWith VircaVirca runs the fix your team approved
ApprovalTodayUsually decided in the momentWith VircaSet in advance. With approval mode on, every run an alert starts waits for approval in Virca.
After the fixTodayUsually someone watches the graphsWith VircaVirca re‑checks its own target. If a step fails, the reverse steps its author wrote run in reverse order. If there are none, recovery is manual, and the record says so.
The recordTodayOften spread across chat and shell historyWith VircaEach run: who or what started it, commands, server, result
Next timeTodayThe same fix, typed againWith VircaThe same approved fix, on every server your team approved it for
A fix can only call functions already on the Worker. It runs only on the servers you assigned. When none fits, Virca stops and tells your team.

The fix runs. The rotation stays. Your engineer sets the scope. AI works within it. Your team approves it. The Worker runs it.

Keep going

One alert, start to finishWhat happens when an alert firesControlHow your team draws the lineExamplesFixes for common alerts
Put your first fix to work →Questions first? ask@virca.ai
Illustration: start with one fix on one server. Your team approves the ActionBook first, then the Virca Worker runs it on server web-01.