> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sixtyfour.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitors Overview

> How monitors keep watched fields on a table of people or companies current, and how checks, events, and schedules work.

A monitor watches a table of people or companies and re-checks chosen fields on a schedule. When a value changes, the monitor records the change with its sources and can notify your webhook.

<Note>Monitors are available to organizations with Monitors enabled. Requests from other organizations return `403`. Contact [support@sixtyfour.ai](mailto:support@sixtyfour.ai) for access.</Note>

<Card title="API Reference" icon="code" href="/api-reference/monitors/create-monitor">
  See the full request/response schema and parameters in the API Reference.
</Card>

## Concepts

| Term | Meaning |
| - | - |
| Monitor | One table, created from a list of rows, with one schedule. Its settings (watched fields, frequency, tier, webhook) apply to every row. |
| Row | One person or company in the table. Each row has its own current values, event history, and on/off switch. |
| Subject | The values that identify a row, taken from the row's `key_columns` (for example `company_name` and `domain`). A subject is never re-derived. |
| Watched fields | The fields the monitor keeps current, passed as `struct`. Same shape as the enrichment `struct`: a description string, or an object with `type`, `description`, and `subfields` for nested fields. |
| Baseline | The values a row currently holds for its watched fields. Every reported change updates it. |
| Subject type | `company` re-derives fields with Company Intelligence. `lead` uses People Intelligence. |
| Tier | Depth of the full re-check: `low`, `medium`, or `high`. |

A column cannot be both a key column and a watched field. `POST /monitors` and `POST /monitors/upload` reject two rows with the same subject values. The workflow `monitor` block watches such rows once.

## How a check works

Every tick of the schedule checks each active row in the monitor.

```mermaid theme={null}
flowchart TD
    A[Schedule tick] --> B[Each active row]
    B --> C{Baseline setup still needed?}
    C -- Yes --> D[Enrich watched fields at the monitor tier]
    D --> E[Report uploaded values that are already stale]
    C -- No --> F[Probe: has anything changed since the last check?]
    F -- No --> G[completion event]
    F -- Yes --> H[Re-check watched fields at the monitor tier]
    H --> I[change event per field that moved]
    E --> J[Webhook notification]
    G --> J
    I --> J
```

* Baseline setup: a watched field whose name matches a column in the uploaded row starts from that cell. Setup enriches an incomplete row at the monitor's tier and reports a `change` for every uploaded value that is already out of date. Fields with no uploaded value get their first value. Rows whose input supplies every watched field skip full baseline setup and wait for the schedule, where they start with the probe. This applies to API rows, file uploads, upload handles, saved workflow results, and the workflow [`monitor` block](/api-reference/workflows/workflow-blocks#monitor).
* Later checks: the monitor looks at the row's known sources and fresh search results, then runs a lightweight probe that asks whether any watched field changed since the last check. Most checks end here with a `completion` event.
* Re-check: when the probe finds a likely change, the monitor re-derives the watched fields at its tier and records one `change` event per field whose value moved, with sources, confidence, and a justification. A value equal to the field's most recently reported value is not reported again, so a field that changes back reports each transition once.
* Failures: a check that cannot finish records an `error` event and leaves its time window open. The next check re-examines the same window, so no change is lost to a failed run.

## Events

Each check has an `event_group_id` shared by every event it produced.

| `event_type` | Meaning |
| - | - |
| `change` | A watched field's value changed. Carries `previous_value`, `current_value`, and a `payload` with `sources`, `confidence` (0–100, or `null` when the field was not scored), `justification`, and your `metadata`. `payload.first_run` is `true` when the first check found the uploaded value stale. |
| `established` | A field received its first value: either the value uploaded at creation or the first value a check found. Recorded for history only. It does not count as a change. |
| `completion` | The check ran and found no change. `payload` describes what was checked and the time window. Hidden from event listings unless `include_completions=true`. |
| `error` | The check could not run. `payload.reason` explains why, for example `insufficient balance`. |

## Frequency

`frequency` is a whole number followed by a unit: `m` (minutes), `h` (hours), `d` (days), or `w` (weeks). For example `6h`, `1d`, or `2w`. The default is `1d`.

* The supported range is `1h` to `30d`.
* `5m` is a testing frequency available only to organizations with it enabled. Other organizations receive `403`.
* Schedules align to UTC. An hourly monitor fires at the top of each hour and a daily monitor at 00:00 UTC. `next_run_times` on every monitor response lists the next three fire times.
* `first_check: "now"` (default) runs setup immediately only for rows missing watched values. Rows with every watched value supplied wait for the schedule, even in a mixed table. `first_check: "next_tick"` defers all rows to the first scheduled fire.
* Checks never overlap. If a tick is still running when the next one is due, the next one is skipped.

## Billing

For setup, probe, and re-check charges, see the [Credits & Pricing Guide](/guides/credits-and-pricing#monitors).

## Access and ownership

* A monitor belongs to the team of the credential that created it. Only credentials for that team can read or change it. Other teams receive `404`.
* A monitor runs on behalf of the API key or user that created it. If that API key is revoked or expires, or the user leaves the organization or the team, the affected rows pause and `disabled_reason` is set to `key_revoked`, `owner_removed`, or `team_removed`.
* When the team's spend limit is reached, checks are skipped until the limit clears.

## Errors

For error responses (400, 403, 404, 409, etc.), see [Handling Errors](/api-reference/errors).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.