VIRCA
Install the Agent

Why it matters

For the person carrying the pager

Ten nights, before the agent and after it

Every card shows how far the pass got. Often the useful answer is that it stopped early — and nobody was woken either way.

Six ways a night ends

For whoever owns the on-call rotation

When the approved set covers it, it is fixed and confirmed. When it doesn't, it stops somewhere honest.

An action is four steps — validate, investigate, act, confirm — and it can stop at any of them. Which ending an event gets was settled in daylight, when your team approved the ActionBook — the commands your engineer named, in the order AI wrote, read back and signed before it ever ran. Nobody decided it at 2am. The trace on each card shows where it stopped.

01

All four steps

Fixed and confirmed

Inside the approved set. Evidence captured, action run on the host, target re-checked. Reported in the morning, not asked at night.

02

Pauses before Act

Asks first

Approved, but marked as needing a tap for this target. The evidence arrives with it, so whoever taps knows what they are answering.

03

Stops at Investigate

Findings only

Real, but no approved action covers it. Your team gets the facts already gathered and makes the call with them in hand.

04

Stops at Validate

Closed on its own

Validated as noise or expected load. Recorded with what was checked. Nobody is called — and that is the design, not a shortfall.

05

No Act at all

Notify only

Something is coming that Virca does not act on. It tells your team early instead of pretending it can fix it.

06

Across passes

And it accumulates

Every pass is on the record. The fourth occurrence gets read next to the first three — at 9am, by someone awake.

Examples below are illustrative, drawn from common host incidents. No timing claims: Virca removes the human wait — the page, the waking, the login, the looking. Not a benchmarked number.

The cards

For the person carrying the pager

Ten nights, and where each one stopped.

Grouped by how far the pass got, the ones the approved set covered first. Each pair is the same night twice — on the left as it goes today, on the right with the agent already on the host. Further down, they stop earlier. That is the design, not a shortfall.

Fixes it

Before Virca

2:14am page. Log into dashboards, find the memory leak, restart the service process by hand, back in bed at 3:20am. Two or three nights a week.

With Virca

Virca#on-call · 2:14am

Memory leak on app-server-02. Growth curve and open handles captured, then the service process restarted — confirmed answering again a minute later. No one woke up.

Fixed and confirmedEvidence kept before the restart
  1. Validate ✓
  2. Investigate ✓
  3. Act ✓
  4. Confirm ✓
Fixes it

Before Virca

11pm disk alert. Log in, find logs piling up from a debug mode left on, run the cleanup script by hand. Twenty minutes gone, every few weeks.

With Virca

Virca#infra · 11:02pm

/var/log hit 92% on app-server-03. Rotated logs cleared, active logs untouched. 92% → 61%, confirmed under the line. Debug mode still on — flagged for you.

Fixed and confirmedZero interruption
  1. Validate ✓
  2. Investigate ✓
  3. Act ✓
  4. Confirm ✓
Fixes it

Before Virca

A read-only triage tool names the OOM kill quickly. Then you still SSH in and restart the service by hand — fully awake, every time it recurs.

With Virca

Virca#on-call · 2:03am

api-service OOM-killed — memory growth traced to yesterday’s deploy. Restarted 02:04, confirmed answering, still up. Deploy review recommended.

Fixed and confirmedOne pass, all four steps
  1. Validate ✓
  2. Investigate ✓
  3. Act ✓
  4. Confirm ✓
Asks first

Before Virca

CPU pins at 100% at 3am, every week or two. Whoever is awake runs top, sees one process, restarts it, goes back to bed. Nobody learns anything. Next month: same spike, same guess.

With Virca

Virca#on-call · 3:04am

CPU on batch-worker-01 pinned at 100% by nightly-report. Open files, sockets and the 12-minute climb captured first. Restart it?

[✅ Yes][🔍 Evidence]

One tap answered itEvidence taken before the fix
  1. Validate ✓
  2. Investigate ✓
  3. Act — asked first
  4. Confirm ✓
Asks first

Before Virca

The question nobody could answer while evaluating AI tools: what stops it restarting prod when the incident was in staging?

With Virca

Virca#platform · 3:12pm

High CPU on staging-api — restart ran, in scope, confirmed. The same action on prod-api is a separate, approval-only entry. That line was drawn when you approved it.

Scoped by targetScoped when your team signed it
  1. Validate ✓
  2. Investigate ✓
  3. Act — asked first
  4. Confirm ✓
Findings only

Before Virca

Disk climbing on the database host. Nobody has an approved cleanup for it — it is the data directory, not logs — so someone is woken to look, then decides in the dark.

With Virca

Virca#infra · 1:38am

/var/lib/mysql at 88% on db-primary-01, up 11 points in 6 hours. Top consumers, growth curve and the last vacuum captured. No approved action covers this one — over to you.

Findings onlyNothing was changed
  1. Validate ✓
  2. Investigate ✓
  3. Escalated
  4. Confirm
Findings only

Before Virca

The same 3am spike, four times. Nobody has them side by side — each was a restart at 3am and a shrug at 9am. The pattern is there. Nobody has seen it.

With Virca

Virca#platform · 9:00am

4th nightly-report spike in 3 weeks — all four inside the batch window, all on the same open file. Each one restarted and confirmed answering again. Worth a look at the schedule.

Findings onlyRead at 9am, not 3am
  1. Validate ✓
  2. Investigate ✓
  3. Escalated
  4. Confirm
Closed on its own

Before Virca

2:07am page: CPU at 94%. You wake up, log in, run top, see the nightly report doing what it does every night, and go back to bed. Four minutes of work. One night gone.

With Virca

Virca#on-call · 2:07am

CPU 94% on batch-worker-03 — owned by nightly-report, inside its usual window, memory flat. Closed as expected load. Nobody called.

Closed on its ownThe most common ending
  1. Validate ✓
  2. closed here
  3. Act
  4. Confirm
Closed on its own

Before Virca

The endpoint check fails once at 4am and pages. It answered fine on the retry. You learn that after you are already awake.

With Virca

Virca#on-call · 4:12am

/healthz on api-03 failed one check, answered on the next two. Listener up, no restarts, no error rate change. Closed as a flap.

Closed on its ownRecorded, not escalated
  1. Validate ✓
  2. closed here
  3. Act
  4. Confirm
Notify only

Before Virca

SSL renewals live on a calendar reminder. The engineer who set it left. The cert expires at midnight, and you find out from a customer tweet — checkout down for hours.

With Virca

Virca#platform · 9:00am

SSL cert for api.checkout.example.com expires in 14 days. Virca does not renew this — it is telling you while there is still time.

[🔗 ActionBook][📋 Assign]

Notify onlyCaught 14 days early
  1. Watch ✓
  2. told your team
  3. Act
  4. Confirm

Count how many of these end with nothing changed. A tool that only handles the incidents worth fixing leaves most of the pages where they were. That is not a gap in the product. It is the shape of a normal week, and it is why the column marked closed on its own is the one that gives you your nights back. How the noise closes before anyone is paged →

Keep going

How it worksThe four steps in one actionUnder the hoodWhat it may run, and who signed itFAQThe questions people ask first