Skip to main content
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. 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