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

# Deepline Monitors

> A Monitor receives supported provider events, stores accepted rows in the Database, and can start a matching Play.

A **Monitor** represents a supported provider event feed with a defined
scope. It receives upstream events and writes accepted records into a Database
stream. A Play can react to those records, but the Monitor does not contain the
Play's business logic or execute that logic by itself.

The separation allows a feed to remain useful as business policies change.
Ingestion answers which source events enter the workspace. Consumer logic
answers what each accepted event means for a particular process.

## Three filters can have three different purposes

Imagine a team watching job postings at target accounts. The provider feed and
Monitor payload identify the source and available scope. A SQL listener might
select only relevant inserted rows. The Play could then join an account table
and decide whether the posting warrants an alert.

| Boundary | Question it answers |
| - | - |
| Provider feed and Monitor scope | Which supported source events should be accepted? |
| Play SQL listener | Which accepted row changes should start this Play? |
| Play code | What business decision follows from this event and other evidence? |

Filtering only inside a Play does not undo ingestion. For an event-priced
Monitor, a row that the Play ignores may already be an accepted billable event.
Likewise, narrowing one listener does not narrow the stream seen by other
consumers.

## A stream is shared data, not a private Play input queue

SQL listeners identify a supported tool and stream. They are not subscriptions
to a particular Monitor key. A feed can therefore support several Plays,
queries, dashboards, or exports.

Two teams might share accepted job-posting rows but interpret them differently.
One could react to an executive role; another could measure hiring by function.
Those consumers need different selection or decision logic, not necessarily
duplicate upstream feeds.

When scopes differ, separate Monitors may be appropriate. Sharing is useful
only when the accepted data serves the consumers' needs. A Monitor is not a
promise that every conceivable source, event type, or field is supported.

## A row change starts one listener execution

For a matching change, the listener passes a changed-row event containing the
operation and the before/after row values. An insert has a new row; a delete
has no after row. The Play receives one top-level event, not an automatically
assembled batch of every recent source event.

That boundary is why a listener's immediate input differs from a periodic
report. A report can query accumulated rows. A listener-driven Play starts
from one qualifying change and can read additional context when needed.

This path is also distinct from an inbound Play webhook. A webhook asks for an
execution with an explicit input. A Monitor contributes retained source data
that may be useful even when no listener currently reacts to it.

## Lifecycle and delivery are separate facts

Customer-visible Monitor states are `active`, `billing_suspended`, and
`disabled`. Lifecycle work has a separate Monitor Job: deployment, changes,
cleanup, or recovery can still be in progress or fail.

An active Monitor is not proof that a particular source emitted a recent event.
An empty stream could mean no matching activity, a narrow scope, or a delivery
problem. Health, current Job details, and accepted data provide different
pieces of evidence.

Changing or removing a feed can affect every consumer of its stream. A Play
remaining published does not preserve an upstream subscription that has been
disabled. Conversely, stopping a Play does not necessarily stop the Monitor's
accepted events or billing.

## Monitor economics depend on the feed contract

Some feeds charge at deployment or reactivation and renew while active. Others
charge for accepted events. The applicable definition and pricing determine
which model applies; the name Monitor alone does not establish a price.

Deepline exposes Deepline credits. It does not expose its internal provider
spend as customer usage. Scope, lifecycle state, and pricing must therefore be
understood together when evaluating a recurring feed.

## Continue learning

* [Set up a Monitor](https://deepline.com/docs/plays/set-up-a-monitor.md): inspect, validate, preview, deploy, and connect a listener.
* [Monitor reference](https://deepline.com/docs/_generated/monitor-contract-reference): supported payloads, streams, and lifecycle semantics.
* [Where data lives](https://deepline.com/docs/data-lifecycle.md): retained events and downstream operational records.
* [How Plays work](https://deepline.com/docs/plays/plays-overview.md): the code that interprets a signal.


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