Skip to content

How it works · Step 1 of 4

Validate: is the alert real, or is it something you can close?

Step one checks whether the alert is real. It is the first thing a person on call checks. Sometimes that check is all the alert needed.

The problem

Some alerts only need someone to look.

CPU at 94%: the nightly report. Disk at 91%: a late log rotation. Someone on call opens a laptop and checks the server. Nothing was wrong. The check still took their time.

Illustration: an alert rings. The Worker looks at the server, and the server is already fine.

What Virca does

Virca looks before doing anything else.

The Virca Worker is a process on your server. It watches the server and runs the fixes your team approves. Read‑only checks run first, on the server, not in a model somewhere else.

Illustration: the Worker checks the server and finds it fine, so no one is called.

Noise closes

The condition is gone, or the checks show an expected cause. The record says why, and no one is called.

Illustration: the alert is real, so the Worker gathers readings from the server into a record.

Real, and needs context

The run moves on to Investigate before anything changes.

Illustration: the alert is real but unclear. The run stops and tells a person on your team.

Real, and unclear

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

Not every event ends in an action, and that is the point. Either way, the record keeps what the Worker saw.

What this is not

Validation is not alert tuning.

Your current alerts still reach the same people as today. Validate checks the events your rules raise. New signals stay your team's decision.

Illustration: your team set the rule. When its alert rings, the Worker checks that event on the server, and looks for nothing else.