Watchers
Watchers are standing rules over your estate. Each one describes a pattern and an action to take whenever the pattern matches, and they run continuously against the data in your organization's scope — so findings and hunts appear without anyone having to remember to look.
Open Watchers from the main navigation.
Three kinds of watcher
Watchers differ in what they watch, and that decides what "it hasn't fired" tells you. Each one shows its kind — its plane — on its row:
| Plane | Fires when | Needs |
|---|---|---|
| Stream | Per event, seconds after it arrives. | Telemetry of the kind the rule looks for. |
| Graph | When your entity graph changes. | Entities to have reached the graph. |
| Correlation | When a window closes over two or more earlier signals. | Those precursor signals. |
You don't need to think about the machinery, but the plane is half the answer to the only question anyone asks a rules page: why didn't this fire? A stream watcher only ever sees telemetry you actually ship. A graph watcher only sees what has reached the graph.
Off, Shadow, On
Every watcher is in one of three states, set from the control on its row:
| State | What happens |
|---|---|
| Off | Not evaluated at all. |
| Shadow | Evaluated and recorded to the daily digest. Never opens a hunt and never notifies anyone. |
| On | Evaluated, and takes its action when it matches. |
Shadow is the safe way to find out whether a rule is noisy. Put a watcher in Shadow, leave it for a few days, then look at its Activity — you learn what it would have done without anyone being paged for it.
A few watchers are published as digest-only. Those show Off and On only, because Shadow would mean the same thing as On.
What a watcher does when it matches
| Action | Label | What happens |
|---|---|---|
| Hunt | Start hunt | Starts a Scout hunt in the organization's chosen mode. |
| Notify | Raise finding | Creates a reviewable detection finding and a notification. |
| Digest | Daily digest | Adds the match to the daily "worth hunting today" roll-up. |
| Tag | Tag graph | Applies a graph tag so another watcher can build on it. Structural — it cannot be switched to a different action. |
Hunt-action watchers run in one of three modes — Guided (Scout proposes each step and waits), Supervised (Scout runs but pauses at checkpoints), or Autonomous (Scout runs end to end and reports back).
Every watcher also carries a severity: Informational, Low, Medium, High or Critical. You can raise the floor for your organization so only matches at or above a chosen severity trigger the action.
Can it fire? — the readiness chip
| Chip | Meaning |
|---|---|
| Armed | The data this watcher needs is present. |
| Needs data | It cannot fire yet, and the chip says why — for example "No Process Activity (1007) events in the last 24 h". This is the one to act on: add the missing source. |
| Check unavailable | The readiness check itself didn't answer just now. Usually temporary, and it says nothing about whether the watcher can fire. |
The last two look different on purpose. Needs data is a standing problem you own; Check unavailable means we couldn't look.
Finding things in a large catalog
The catalog runs to thousands of watchers, so the page is built for narrowing rather than scrolling.
- Search matches names, descriptions, ATT&CK techniques (
T1059) and — for watchers whose rule you can read — the rule text. - Filters for state, severity and plane. Each option shows how many watchers are in that bucket, so the dropdowns double as navigation.
- Group by state, severity, plane or ATT&CK tactic, with collapsible sections. A watcher covering several tactics appears under each of them.
- Sort by severity, name or state.
The summary line above the list reports the totals for your search, not just what is currently on screen.
Watchers are enabled per organization
A watcher's state belongs to one organization. The same watcher can be On for one and Off for another, and the controls on the page apply to the organization named at the top.
If you work across several organizations:
- Use the organization picker at the top of the page to switch which one you are setting. The page's address includes it, so a link you share opens on the same one.
- Open a watcher and use its Deployment tab to see its state in every organization you can see, and set each one from there.
Tuning — state, severity floor, action and hunt mode — is that organization's, not the rule's. Changing it doesn't affect anyone else.
The Deployment tab can also set every organization at once. When it does, each organization answers for itself: if one refuses — because the watcher isn't available to it, for example — that row says so and the others still apply. A row that can't run the watcher explains why underneath its name, rather than leaving you with a control that appears to work and a watcher that never fires.
What a watcher has done
Open a watcher to see its Activity for the last 7, 14 or 30 days:
| Reading | What it tells you |
|---|---|
| Fired | How many times it matched and acted. |
| Suppressed | How many further matches were folded into those. A dash means nothing measured it — not zero. |
| Entities | How many distinct hosts, accounts or assets it touched. |
| Hunts opened | How many hunts it started. |
| Daily bars | The shape of the volume: steady, or one bad Tuesday. |
Beneath those, the recent firings list shows what each one produced and how much it suppressed.
Fired 64, suppressed 1,204 is a signal in its own right. A watcher suppressing ten times what it fires is working, and its tuning is wrong — a completely different problem from silence. The page says so when it sees it, and points you at Shadow rather than Off: moving a noisy rule to Shadow keeps its evidence coming while you narrow it.
What changed, and when
Open a watcher's History tab to see every edit: the version number, who made it, when, and the note they left describing the change.
Selecting a version shows what it changed — its rule compared against the rule running now. Added lines are in today's rule; removed lines exist only in the version you selected. Long runs of unchanged lines are collapsed, and the page says how many it hid.
Two things you may see there:
- Older pipeline on a version means it was compiled by an earlier version of Huntbase's rule engine. What it recorded about itself is history, not a promise about how it would compile today.
- If you may tune a watcher but not read its rule, the history is still yours to see — the version list is shown, and the rule text says it isn't readable rather than appearing empty.
For a watcher you own, Restore as new version puts an earlier rule back. It is saved as a new version noting where it came from, not a rewind: the history stays complete, and the restore itself appears in it.
Recent firings on the Activity tab are labelled with the rule version that fired, so a change in volume can be traced to a change in the rule.
Check a watcher against your history
Before turning a stream watcher on, you can run it over telemetry you already have. Open the watcher, and under Looks for use Check against history with a window of 1, 7, 14 or 30 days. You get the number of times it would have fired, how many distinct entities it touched, an expected daily rate, and sample matches.
Two things to read carefully:
- If the number is shown with a ≥, the rule uses a construct the historical query can only approximate. The count is a floor — the real number is at least that, possibly higher.
- Graph and correlation watchers cannot be checked this way, and the page says so rather than offering a button that does nothing. They are standing queries over live state; there is no history to replay.
Write your own watcher
You can write your own stream watchers as Sigma rules. Click New watcher.
The editor is a loop rather than a text box:
- Write the rule. It compiles as you type. When editing, you can leave a short note saying what changed — it is kept with the version and shown in History.
- Read what it compiled to — which data surface it binds to and which fields it uses. If it wasn't accepted, the message says exactly why: an unmapped field, a construct that isn't supported, or that the rule belongs on a plane you don't author.
- Check the field list. It shows the fields the chosen surface actually provides. A rule referring to a field that isn't there saves happily and can never fire, so the editor shows you the difference up front.
- Backtest the draft over your own history, before it is saved.
A new watcher is created in Shadow. The confirmation says so and offers Turn on as a separate click — promoting a rule out of Shadow should be a decision you take after seeing it run.
Your own watchers are marked Yours in the list, and you can edit or delete them. Graph and correlation patterns are written and published by Huntbase.
Some published watchers don't show their rule. Where that happens you can still tune the watcher for your organization, but not read or edit the pattern.
Where watcher output shows up
- Activity Feed › Insights — findings raised by watchers appear as insights. Set the Origin filter to Watcher, and combine it with Needs review to find the ones nobody has looked at. The Source column names the watcher.
- Insight details — a watcher-raised insight names the watcher in its provenance.
- Hunts — a hunt started by a watcher records the watcher, what it matched and the firing event, so you can see why the hunt exists.
- Notifications — watcher hunts, findings, tags and digest entries arrive as Hunt Alerts. See Notifications.
Start a new watcher in Shadow, review its Activity for a few days, and promote it to On once you trust the signal.
Next steps
- Activity Feed — where watcher findings and hunts land
- Insights — reviewing what watchers raise
- Connections — adding the data a watcher needs
- Notifications — how watcher alerts reach you