Observe
For whoever tuned the thresholds
What observability was built for, and who reads it now
The rollups, the dashboards, the months of retention, the carefully tuned thresholds — all of it assumed one thing: a person would be the one reading it.
Built for a reader
For whoever tuned the thresholds
Every part of it was shaped by a person having to read it.
Two generations of tooling grew up on that assumption. The first asked whether the service was alive. The second asked why it broke. Both ended in an explanation clear enough for a person to act on.
What each design decision was protecting
A rollup exists because nobody can hold a hundred gauges in their head. Months of retention exist because the person who needs the data is asleep right now, and will look tomorrow — or next quarter, when somebody asks what happened. A threshold gets tuned until the channel goes quiet to protect a human’s attention, the scarcest thing in the room. None of those choices was about the system. Each one was about the reader.
When the reader changes
For whoever picks the tools
A machine does not need the half that costs the most.
Take that list one item at a time, and ask whether it still holds when the reader is software instead of a person on call.
01
It does not need the chart
Software wants the raw window around one host at one moment — exactly what the rollup throws away to draw a chart for eyes.
02
It does not need to arrive late
Long retention exists because the reader turns up hours or weeks later and has to reconstruct the night. Software is already awake. It can look while the event is still happening — the one moment the data is complete.
03
It does not need the threshold set to human tolerance
Alert tuning is a negotiation with fatigue: too tight and people stop reading, too loose and something slips past. A false positive costs a person their night. It costs software a few seconds of checking.
04
But it does need something nobody asked you for
What this host actually is. What depends on it. What “healthy” means for this specific check, written down instead of assumed. A person fills those in from memory without noticing. Software has to be told.
How Virca observes
For the engineer who runs the host
Observe for action, not for archive.
Virca collects what its actions need, when they need it — not everything, forever, on the chance somebody queries it later. The set grows: every action your team approves brings its own signals with it, and your team can add more.
A small set of core signals stays on. When one moves, the agent checks whether the move is real before it pulls anything more. That check is step one of every pass →
That is also where the overhead goes. The baseline stays narrow — only the signals the approved actions use — and it widens only when something moves, for as long as the event lasts. The widening happens on the host, so the detail never has to travel to be read. What leaves over the single outbound connection is the finding and the result, not the raw window behind it.
During a run the reader is the agent itself. It reads what comes back on the host in front of it, and it never reads outside the ActionBook your team approved.
Core signals, always on
Each action your team approves brings the metrics and the collection interval it needs. Nobody sizes or tunes them by hand.
Full detail, on the signal
Once an event checks out as real, the agent pulls what the situation calls for: which process is burning the host, and what it was talking to.
The chart comes to you
Charts did not disappear. You just stopped having to go and find them. The one that explains the incident arrives attached to the report and to the record, at the moment it matters.
Keep the monitoring you already run
Virca runs alongside it and does not depend on it. Yours collects so your team can look. Virca’s collects so its own action can run.
What Virca did is a different matter, and it stays on the record: every execution keeps its trigger, decision, commands and outcome. “Not for archive” says what we collect for — not a door we have closed.