How it works · Step 3 of 4

Act: the approved fix runs on the server that raised the alert.

The Virca Worker is a process on your server. It watches the server and runs the fixes your team approves. If no approved fix fits, it stops and tells your team.

Illustration: nginx stopped on server web-01. The alert started the restart your team approved, and the Worker ran it right away. Restart nginx: done. — nginx stopped on web-01. The approved restart runs right away.
Your team linked this alert to a restart. With approval mode on, the restart waits for one tap.
Your team starts this cleanup. An alert does not start it.

nginx stopped on web-01. The approved restart runs right away.
Your team linked this alert to a restart. With approval mode on, the restart waits for one tap.
Your team starts this cleanup. An alert does not start it.

Where it runs

The fix happens where the problem lives.

The Worker runs the fix right there on the server.

One outbound TLS connection, no inbound, credentials that stay on the server →

Illustration: the Worker on the server runs the fix your team approved.

Nothing to assemble first

Once the Worker is installed, it can run approved fixes on the server.

Illustration: two servers side by side, a cloud VM and a bare-metal server.

The Linux and Windows servers you run

Web and app servers, on cloud VMs and bare metal. Kubernetes is outside launch scope.

What it may run

A set your team approved, on servers your team assigned.

A fix can only call functions already on the Worker, with no shell escape. Each function was declared with its own limits and grade.

With approval mode on, every run an alert starts waits for approval in Virca.

Illustration: your team approves an ActionBook once, and the Worker on each assigned server, web-01, web-02 and web-03, runs it.

After approval

Approved once means approved, not unsupervised.

Each run stays inside the line your team drew, and reports back. Approvals and scope →

Illustration: a line surrounds the Worker and the two servers your team assigned. A faded server sits outside the line, and its link is crossed out.

Only on assigned servers

The fix runs only on the servers your team assigned.

Illustration: the fix did not hold. Where its author wrote reverse steps, they run on the server in reverse order.

Reverse steps, where written

If the fix didn't hold, the reverse steps its author wrote run in reverse order. If there are none, recovery is manual, and the record says so.

Illustration: nothing fits, so the run stops. The Worker sends a person on your team a message with what it found.

No approved fix fits → your team hears

The run stops and tells your team what the Worker found.

Illustration: the Worker runs the fix on a server. Who or what started it, what ran and what happened next go into the record.

Every run on the record

Who or what started the run, what ran, and what happened next.

Keep going

The fix ranStep four — did it hold?Approvals and scopeThe boundary and the record Before and afterWhat changes with Virca

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.