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

# Monitor Targets

> Attach a Monitor to one or more intents, workflows, or agents at a sample rate

A **Monitor Target** wires a Monitor to a specific production surface and tells the runtime how often to sample it.

A Monitor is inert until at least one target is attached and the Monitor's status is `ACTIVE`.

## Target types

| `target_type` | What it watches                                                                                          |
| ------------- | -------------------------------------------------------------------------------------------------------- |
| `intent`      | Every chat completion request that lands on this Intent (across all applications using this intent type) |
| `workflow`    | Every completed `workflow_run` for this Workflow                                                         |
| `agent`       | Every completed root `agent_request` for this Agent (sub-agent steps are not double-counted)             |

## Attaching a target

In the Monitor detail page, open the **Targets** tab and click **Attach Target**. Pick the resource type, search for the target, and set:

* **Sample rate**: `0`–`100`. The runtime takes a uniform random roll on each completion; a sample rate of `5.0` means roughly 5% of invocations will fire a `monitor_run`. Set to `100` to evaluate every invocation.
* **Enabled**: toggles sampling for this attachment without detaching it.

Each target carries its own sample rate. The same Monitor watching `intent: order_intake` at 5% and `workflow: order-intake-workflow` at 100% is a normal pattern.

## Sampling decision

When a production event completes (chat request, workflow run, or agent request), the runtime:

1. Looks up active Monitors attached to that target
2. For each, takes a uniform random roll vs the target's `sample_rate`
3. If the roll passes, dispatches a runner invocation (model / workflow / direct) on the latest published version of the Monitor
4. Inserts a `monitor_run` row with the verdict + decorated trace

Steps 1–3 happen out-of-band, they never block the production response. If sampling errors out for any reason it's logged but doesn't affect the user-facing call.

## Editing a target

From the Targets tab you can:

* Update the sample rate (raise it during incident triage, lower it once the Monitor is stable)
* Disable a target (sampling stops; history is preserved)
* Re-enable a previously disabled target
* Detach a target entirely (soft-delete; history is preserved but no new runs)

Updating a target is immediate, the runtime picks up the new sample rate on the next event.

## Per-target metrics

The Monitor's **At-a-Glance** section shows a per-target card, its type, sample rate, error rate, and a 24h error-rate sparkline. This is the fastest way to spot which target is misbehaving when the same Monitor watches multiple resources.

Next: [Versions and releases](/observe/monitors/versions).