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

# Set up a Monitor

> Validate, preview, deploy, and inspect a scoped Deepline Monitor before it starts accepting provider events.

Use this guide to deploy a scoped provider event feed. A **Monitor** receives
events pushed into Deepline by a supported external source and writes accepted
rows to the Database. A **Play** is separate: it runs code when a matching row
reaches a stream.

<Info>
  A Monitor accepts data; it does not contain the code that reacts to it. Read
  [How Monitors work](/docs/plays/monitors) for the product model.
</Info>

## Before you start

You need an authenticated Deepline workspace with Monitor access. Know which
source events you want to accept and the smallest scope that produces useful
data.

## 1. Check access and inspect supported types

```bash theme={null}
deepline monitors status --json
deepline tools list --categories monitors
deepline tools describe deepline_native.company_radar --json
```

The list returns the Monitor tool IDs available to your workspace. Replace
`deepline_native.company_radar` with one of those IDs, then use its returned
payload schema. Available Monitor types, streams, output tables, and pricing
depend on your workspace and the provider.

If the source might already be covered, inspect the existing registry before
you deploy another feed:

```bash theme={null}
deepline monitors list --status all --json
MONITOR_KEY="acme-job-openings" # Replace with a key returned by the list.
deepline monitors get "$MONITOR_KEY" --json
```

One Monitor can supply a stream to several Plays. Reuse a Monitor when its
existing scope already covers the events you need.

## 2. Define the narrowest useful scope

Save a definition as `monitor.json`. This example watches job openings at one
company through the Deepline Native company radar:

```json theme={null}
{
  "key": "acme-job-openings",
  "tool": "deepline_native.company_radar",
  "payload": {
    "domain": "acme.com",
    "radar_type": "company_job_openings"
  }
}
```

Replace the key and payload with the schema returned by
`deepline tools describe deepline_native.company_radar --json`.
Scope the Monitor itself rather than accepting a broad feed and filtering only
in a Play. For an event-priced Monitor, a Play filter does not reduce the
events the Monitor accepts.

## 3. Validate without deploying or spending credits

```bash theme={null}
deepline monitors check --file monitor.json
```

`check` validates the definition. It does not deploy a Monitor, create an
upstream resource, or spend credits. Resolve every validation error before you
continue.

## 4. Preview the deployment, then deploy

```bash theme={null}
deepline monitors deploy --dry-run --file monitor.json
```

The dry run shows the deployment plan, including available price information
and any existing Monitor that may already cover the scope. It does not deploy
or change upstream resources.

If the scope and price are right, deploy the definition:

```bash theme={null}
deepline monitors deploy --file monitor.json
```

This is the step that activates the provider event feed. Monitor pricing can
apply at deployment or reactivation, per accepted event, or at renewal. The
CLI shows Deepline credits, not provider spend.

## 5. Confirm the live Monitor

```bash theme={null}
deepline monitors get acme-job-openings --json
```

Confirm the Monitor is active, its output stream and Database table match
the intended data, and its scope has not widened. The response also shows
connected Plays and their current listener health when available.

## 6. Connect a Play to the stream

Generate a Play scaffold for the Monitor's exact tool and stream:

```bash theme={null}
deepline plays bootstrap monitor-triggered \
  --tool deepline_native.company_radar \
  --stream company_job_openings \
  --out on-job-opening.play.ts
```

The generated Play uses a `sqlListeners` trigger. Keep the tool and stream
aligned with the Monitor, then narrow its `where` filter to the rows that
should run code. Put joins and business decisions in the Play body, not in the
Monitor definition.

Check and publish the Play when its logic is ready:

```bash theme={null}
deepline plays check on-job-opening.play.ts
deepline plays publish on-job-opening.play.ts
```

After publishing, a matching Database row starts the Play. There is no
polling job or manual Monitor run.

## Change or remove a Monitor safely

Inspect the Monitor and its connected Plays before changing it. Its output
stream can also feed queries, dashboards, exports, or warehouse jobs.

```bash theme={null}
deepline monitors get acme-job-openings --json
deepline monitors delete acme-job-openings --dry-run
```

Delete only after reviewing the plan. The actual deletion command deprovisions
the upstream provider resource:

```bash theme={null}
deepline monitors delete acme-job-openings --yes
```

<CardGroup cols={2}>
  <Card title="How Monitors work" icon="radar" href="/docs/plays/monitors">
    Understand the event path and the boundary between a Monitor and a Play.
  </Card>

  <Card title="Where data lives" icon="database" href="/docs/data-lifecycle">
    Decide when an event belongs in the Database and when an outcome belongs in a
    CRM.
  </Card>

  <Card title="Monitor contract reference" icon="code" href="/docs/_generated/monitor-contract-reference">
    Inspect supported Monitor payloads, streams, outputs, and update semantics.
  </Card>
</CardGroup>