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

# Versions and Releases

> Freeze a Monitor as an immutable snapshot and pin production to it

Monitors version like Workflows and Agents: every saved edit lives on a mutable **draft**, and you **publish** to freeze a snapshot for production use.

## Why publish?

The runtime always evaluates against a *published* version, never the draft. Without a published version, the Monitor is inert in production even if it has targets and is `ACTIVE`. Publishing also gives you a rollback target if a new resolution turns out to be too noisy.

## Versions

Each publish snapshots the Monitor's name, description, and config (runner + resolution) into an immutable `monitor_version` row. Versions are numbered semver-style (`1.2.0`), and the Portal infers the increment from the kind of change (or you can pick `major` / `minor` / `patch` explicitly).

The `latest_version_number` and `has_unpublished_changes` flags surface on every Monitor:

* `latest_version_number`, the most recent published snapshot
* `has_unpublished_changes`, `true` when the working draft differs from the latest snapshot

## Releases

A **Release** is a named pointer to a specific `monitor_version`. The most common releases are `prod` and `staging`, but you can name them whatever fits your workflow. One release per Monitor can be flagged `is_default=true`, that's the version the runtime resolves when sampling fires.

Typical flow:

1. Edit the draft (configuration changes, resolution tweaks)
2. **Publish** the draft, creating a new `monitor_version` (e.g. `1.3.0`)
3. **Promote** the `prod` release to point at the new version when you're ready
4. If something goes wrong, **promote** `prod` back to the previous version, no code changes, no redeploy

## Where to manage versions

In the Monitor detail page, the **Versions** tab shows the full publish history with version notes
and timestamps. Release management lives in the same flow, from here you can:

* Create / rename releases (e.g. `prod`, `staging`, `canary`, `preview`)
* Promote a release to point at any published version
* Mark a release as the default
* Delete a release (the underlying version is preserved)

## Programmatic access

Versioning is fully exposed under [`/api/v1/monitors/{monitor_id}/versions`](/api-reference/overview) and `.../releases`. Agents can publish a new version, promote a release, or roll back without touching the Portal.

Next: [Reviewing results](/observe/monitors/results).