> ## 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` rejects 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{First check for this row?}
    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
```

* First check: a watched field whose name matches a column in the uploaded row starts from that cell. The first check enriches the 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. Monitors started by the workflow [`monitor` block](/api-reference/workflows/workflow-blocks#monitor) skip this full first check for rows whose input already supplies every watched field.
* 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) checks every row as soon as the monitor is created. `first_check: "next_tick"` waits for 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

After a row's first check, every tick bills a probe for that row. The full re-check is billed at the monitor's tier only for rows where the probe found a likely change. The first check of each row is billed at the monitor's tier. Switched-off rows and cancelled monitors are not billed. The probe, first check, and re-check are billed separately, and each is charged only if it runs to completion. A probe that completed is still charged when the re-check after it fails.

Monitor charges appear in usage logs as `monitor_recheck`. See [Credits & Pricing Guide](/guides/credits-and-pricing) for more information.

## 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).