What observing is for

Virca collects what your approved fixes need.

The Virca Worker is a process on your server. It watches the server and runs the fixes your team approves. It collects CPU, memory, disk, processes and URL checks: the signals those fixes need. Your team reads them, and the Worker reads them too.

Illustration: on one side, a person reads a dashboard. On the other, the Worker reads the server’s data itself.

Built for a reader

Today, a person reads it.

Rollups, charts and tuned thresholds exist so a person can act on the data.

What each design decision was protecting

A rollup exists so a person can read many metrics in one chart. Months of retention exist so a person can read the data later. That might be the next morning, or when someone asks what happened. A threshold gets tuned so a person sees fewer alerts. Each choice protects the person reading it.

Illustration: a dashboard, documents and an alert, read by a person on your team.

When software reads it too

When software reads it too, server data can start a fix.

Here is the same list when software reads it as well as a person on call.

Illustration: your team keeps the chart. The Worker reads the server’s data directly.

Software skips the chart

Software wants the raw window around one server at one moment.

Illustration: the server raises an alert, and the Worker is already reading that server’s data.

Software is already on the server

Software can look while the event is still happening.

Illustration: a false positive costs a person time. For the Worker, it is one quick check on the server.

A false positive takes one quick check

Software checks the server first. If the problem is already gone, the run ends there, and no one is called.

Illustration: a checklist your team wrote about the server goes to the Worker on that server.

But software needs context written down

What the server is, what depends on it, what “healthy” means here. Your engineer adds that when correcting the fix.

How Virca observes

Observe for action.

Virca collects what its fixes need, when they need it. Each fix your team approves brings its own signals. When a core signal moves, the Worker checks that the move is real before collecting more data. That check is step one of every run →

Illustration: the Worker keeps a small set of core signals from the server, always on.

Core signals, always on

CPU, memory, disk, processes and URL checks. Beyond those, the approved fixes decide what is collected.

Illustration: when a signal moves, the Worker checks it and records the full detail.

Full detail, on the signal

Once an event is real, the Worker records the process detail.

Illustration: the chart reaches a person on your team, by email.

The chart comes to you

The chart that explains the incident arrives with the record.

Illustration: your current monitoring keeps its dashboard, and the Worker runs on the server, separate from it.

Keep the monitoring you already run

Virca runs alongside your monitoring and doesn't depend on it.

Keep going

Then an alert firesStep one — is the alert real?ExamplesFixes for common alerts ControlWhat Virca may run, and who approved it

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.