Skip to main content
A search answers a question now. Monitoring keeps asking it for you: you hand the platform an asset to watch — a domain, a brand, a query — and it re-runs the search on a schedule, recording every new hit and notifying you. (In the dashboard this is the Alerts section.)

​
How it works

Monitoring is built from a few pieces that fit into a loop:
  1. A monitoring rule ties one data source to one asset. The data source is an alert service — Telegram, leaked credentials, phishing, certificates, ransomware, and the rest of the catalog. The asset is the rule’s args — the domain, brand, or query you want watched.
  2. The platform runs the rule on its schedule. Each run searches that source for hits new since the rule last ran — so you only ever see fresh exposures.
  3. New hits are recorded as a match (an incident in the dashboard) and delivered to your email recipients and/or a webhook.
  4. You read and triage matches, export them, and suppress the false positives with an exclusion list.
  5. Metrics roll it all up — how much is hitting, on which sources, over time.

​
Set it up

1

Create a rule

Pick a data source, give it your asset, set how often it runs, and attach delivery. → Create a monitoring rule
2

Wire up delivery

Configure the email senders, recipients, and templates — or a webhook — that matches are sent to. → Delivery: email and webhooks
3

Read the matches

List incidents, open one, page its hits (the shape depends on the source), triage, and export. → Read and triage matches
4

Cut the noise

Build a per-rule exclusion list — by hand or by uploading a CSV — to suppress known-good results. → Exclusion lists
5

Watch the numbers

Pull the overview, the monthly distribution, and per-service hit counts. → Metrics
Every endpoint in this section is tagged alert-system in the API reference and is org-scoped — calls resolve to your organization automatically.