How it works · Step 2 of 4
Investigate: what the alert left out
Step two gathers the facts the alert didn't carry, on the server. Getting them by hand usually means someone on call logs in and types commands.
The gap
An alert tells you a number. It leaves out the situation.
“Memory above 90% on web-02” is true and nearly useless. Which process? Since when? What changed? Each answer is a command someone types after logging in.
What Virca does
Evidence on the server, before the fix runs.
The Virca Worker is a process on your server. It watches the server and runs the fixes your team approves. Approved read-only checks run where the problem is.
Evidence first, then the fix
A restart can clear the evidence, so the snapshots come first.
Every run goes on the record
Your team can compare this run's findings with the runs before it.
Sometimes findings are the whole answer
When a port stops answering, the findings reach your team by email or Slack, with the detail attached.
What this is not
Gathering facts is not naming a cause.
Virca collects the facts. Naming the cause stays with your team.
Exactly where the line sits
Virca names which system or which process is implicated, with the evidence it used. Then Virca stops. Past that, it is a code question. A code question belongs to the team that wrote the code.
