Skip to main content

Continuous monitoring

Open Monitors in your personal account, or from the selected Teams research space. Create a monitor, give it a name and add domains or IP addresses, one per line. A domain includes its subdomains. Up to 100 starting points can share one monitor; use separate monitors when partners need different rules or destinations.

The monitor matches observations arriving from DNS, WHOIS, certificates and hosts. It does not continuously search Elasticsearch or Scylla. Creating a monitor, reading its journal or refreshing its profile does not start an active scan or spend search credits. Coverage depends on the recon stream; no event is not proof that nothing changed.

Replacing the previous monitors​

Previous personal alerts and Teams scheduled monitors stop at cutover. Their configurations are retained, but are not automatically converted into continuous monitors. Create a new monitor to resume tracking. Existing historical records are not imported into the new journal. Retention and account-deletion policies continue to apply. Exposition's separate collection workflow is unaffected.

What the journal means​

The first snapshot of a declared starting point is silent. Repeated observations are deduplicated. A changed IP or DNS value can enrich evidence for a known asset; it does not make that asset newly discovered. Announcing a new asset requires a reliable first-seen date. Older or undated observations are not presented as new.

Open an event to see its source, value, observed time and matching reason. Mark visible events as read when reviewed. The Scope tab shows retained assets; Review separates candidates, references and exclusions. Sharing a service or certificate is evidence of a possible relation, not ownership. Accept candidates explicitly before adding them to the followed scope.

Profile summarizes values already collected for the monitor. You can choose a discovery signal, inspect its effect and save the change. Advanced rules can combine predicates and correlate conditions on the same asset within a bounded time window. They do not automatically prove compromise.

The source-health indicator distinguishes a connected stream, delayed activity and a stream still awaiting observations. The journal retains events for 90 days; asset evidence remains with the monitor within its storage limits. Deleting a monitor removes its associated records. Historical archive checks are disabled at launch; the API reports archives: false and rejects archive requests with 503 archive_disabled.

Notifications and capacity​

Choose the in-app activity feed, a daily email summary or immediate email when included in your plan. Optional webhooks use signed deliveries and expose retry status. Destinations count against the organization's shared webhook capacity.

Flex includes 15 configured monitors in its base configuration; purchased capacity is shown in the interface. Paused monitors still count as configured monitors and preserve their data. Delete an unneeded monitor or increase the subscription's capacity. Creating one does not allocate extra search credits. Trials allow 3 monitors; existing Teams and Teams Plus entitlements remain 15 and 40 respectively. Monitors in one client consume the same organization-wide allowance as monitors in other clients.

Service API​

Use the explicit prefix:

/api/v2/service/organizations/{organization_id}/clients/{client_id}/followups

A pb2b_ key needs watches:read to read the journal, monitor definitions, assets, profiles and delivery status. Acknowledging events also uses watches:read. Creating or changing a monitor, reviewing candidates or changing a webhook requires watches:write and current access to the selected client. Use both scopes for an integration that manages and reads monitors.

POST /api/v2/service/organizations/{org}/clients/{client}/followups/
Authorization: Bearer <service-key>
Idempotency-Key: partner-monitor-create-001
Content-Type: application/json

{
  "name": "Partner infrastructure",
  "state": "active",
  "delivery": "inbox",
  "notify_kinds": ["first_observed", "scenario"],
  "definition": {
    "seeds": ["example.com"],
    "sources": ["hosts", "dns", "vhosts", "whois"],
    "signals": [],
    "exclusions": [],
    "scenarios": []
  }
}

Use a stable idempotency key when creating the monitor. A machine credential is not an email recipient, so service-key requests must select delivery: "inbox". A webhook can be configured separately with POST /{id}/settings and {"url":"https://your-endpoint.example/hook","enabled":true}. Save the signing secret returned at configuration in a secret manager.

  • GET /: list the client's monitors.
  • GET /journal?unread=true: read activity across this client's monitors.
  • GET /{id}/events: read a monitor's activity; paginate with the returned cursor.
  • GET /{id}/assets?state=candidate: inspect candidates before accepting them.
  • POST /{id}/update: submit the complete definition and its current version.
  • POST /{id}/review: send asset, action (accept, exclude, restore) and version.
  • POST /{id}/read: acknowledge through the string cursor returned by the journal.
  • POST /{id}/delete: provide the current version in If-Match.

A stale version returns a conflict; refresh before changing the definition. Organization monitors belong to the organization, not the key that created them. Rotating or revoking a key stops that key's access; pause or delete the monitor to stop tracking. Client removal and organization entitlement are checked by the monitoring engine too. Organization-wide portfolio access is a human-session feature; service keys remain restricted to their assigned clients.

See the service API reference and its OpenAPI contract for the complete route inventory. The former /watches write routes return 410 monitors_replaced; they no longer schedule searches for Teams.

Last updated on