Event
For whoever tuned the thresholds
An event is a question. The answer used to be a person’s name.
The threshold, the severity, the link at the bottom of the alert — every field on an event was designed around who would be woken up.
Addressed to a human
For whoever tuned the thresholds
Every alert in your stack has a person at the end of it.
An event looks like a statement about the system. Read the fields one at a time, and most of them are statements about people.
01
The threshold is set to a person’s patience
Not to the point where the system starts misbehaving — to the point past which the on-call rotation will put up with being told.
02
Severity is a sleep schedule
P1 wakes somebody now. P2 waits until morning. That is a roster decision dressed up as a property of the system.
03
The link at the bottom is a document
The runbook exists because the alert cannot do anything itself. It is instructions for a person to read at 2:14am and retype by hand.
Change the addressee
For whoever picks the tools
Change who receives it, and every field means something else.
01
Severity stops meaning “who wakes up”
When the receiver can act, the only question worth grading is whether the act can be undone. Severity becomes a statement about reversibility.
02
The cost of being wrong collapses
If something checks the event before any person hears about it, a false positive stops being expensive. The pressure that kept thresholds tight for a decade was protecting human attention — and it comes off.
03
And a problem appears that people solved without noticing
A person reads twenty alerts from one cause as one incident. Software does not. A burst of events becomes a burst of runs unless something folds it first, at the event.
How Virca handles events
For the engineer who has to approve it
The rule does not page a person. It binds an ActionBook.
A rule crosses, and the ActionBook bound to it runs on the host that raised it — the book your engineer named the commands for and your team approved in daylight. Your team is told what happened. Nobody is woken to do it.
The binding is the approval
Your team approves when it binds the ActionBook to the rule — in daylight, with the exact commands and hosts on screen — not at 2:14am when it fires. That is what “approve once” means. Approved once means approved, not unsupervised.
A gate before anything is sent
Every action carries a grade. On the AI path, that grade decides what happens next: routine ones run, ones that need a second look wait for one tap in your team chat, and anything irreversible is refused outright — on the server, before the Agent is told anything. Where that gate sits, and what it refuses →
Bursts fold before they become actions
A run of related transitions collapses into one event, carrying the highest severity in the burst, before anything executes. Notifications mute for a set window, and a repeat of the same ActionBook on the same target is dropped. The folding happens at the event, so a burst reads as one incident instead of one run per transition.
The event and its outcome stay together
What fired, what it was bound to, what ran and how it ended sit in one record — filterable, and linkable to a single incident for the retro.
Not every event ends in an action. Plenty close because the check found the alert was not real. Plenty close with the findings attached and a person deciding what to do in the morning. None of them wake anybody.