Duplicate or noisy alerts

The same event alerted twice

Watcher deduplicates on event identity (evidence URL plus the normalised quote and date) and then on meaning. A genuine duplicate usually has one of these causes:

Cause	How to confirm	Fix
Two genuinely different announcements at one URL	Compare the two evidence quotes — a notice board adding a second row is two events	Working as intended; narrow the condition if you only want one of them
The embedding service was unavailable	The run happened during a provider outage	None needed. Semantic deduplication is skipped rather than blocking a real alert, so a duplicate can slip through
Two watches cover the same thing	Both watches show a notified run at the same time	Merge them — watches do not share memory with each other
The watch id changed	A new id has no memory of previous alerts	Keep ids stable
Two schedulers are running	A scheduled job and an always-on service against one database	Set SCHEDULER_ENABLED=false on the service

Too many alerts overall

Work down this list in order — the first two are far more effective than moving thresholds.

1. Tighten the condition first

Most noise is a condition that says what should fire but never says what should not. Add an explicit exclusion list:

condition: >
  Alert only when the official result is declared. Do NOT alert on exam-date
  announcements, admit cards, answer keys, coaching or news commentary, or
  speculation about when the result might come.

See Writing a condition.

2. Narrow the sources. A broad search source is the usual noise generator. Pin it:

- type: search
  value: "2026 examination result declared"
  hints:
    officialDomains: ["example.gov"]
    recencyDays: 14

3. Grade the noisy domains. Mark a site that keeps producing junk as low and it can never lift an alert above the weak tier. See Manage the trust registry.

4. Then adjust the bars. Raise threshold, or require corroboration:

threshold: 0.7
minSources: 2

5. Or turn off the weak tier. Removing weakThreshold stops all “unconfirmed” alerts — you will get less, and you will also hear nothing about borderline evidence.

Alerts about the wrong subject

A similarly-worded story about a different product, exam or project matched. The fix is in the condition, not the thresholds: name the subject explicitly and exclude the neighbours.

condition: >
  Alert only about the 2026 cycle of examination X. Ignore examination Y, and
  ignore any earlier cycle (2024, 2025).

Too many “unconfirmed” alerts

That tier exists to surface borderline evidence, so some volume is expected. If it is constant, the usual cause is that your sources are not graded — an ungraded source cannot produce a confirmed alert, so everything arrives unconfirmed.

Add a trust rule for the domains you actually trust; see Source trust. If you would rather keep them ungraded, raise weakThreshold so only stronger borderline evidence reaches you.

Measure instead of guessing

Label a dozen alerts 👍/👎 in the panel or the app, then read the rolling precision and recall with the recent false positives listed. That turns tuning into evidence. See The feedback loop and Tune precision.