# Monitors as code

> Monitors as code endpoints of the StatusTick REST API: plan a monitors file sync, sync a monitors file, with parameters, responses and examples.

## Plan a monitors file sync

`POST /v1/monitors/managed/plan`

What `PUT /v1/monitors/managed` would create, change, take over (`ADOPT`) and delete for this file, field by field; changes nothing, so a `READ` key is enough. The `statustick` CLI (`statustick sync --dry-run`) calls it. An entry with an `id` of a monitor made by hand is planned as `ADOPT` even without `adopt`.

## Sync a monitors file

`PUT /v1/monitors/managed`

Needs a `READ_WRITE` key. Makes the monitors a monitors file manages (`managedBy: FILE`, `managedKey` = the entry's `key`) match `monitors`: creates new keys, changes what differs and deletes FILE monitors whose key is gone (unless `prune` is false). Monitors made in the dashboard are never touched, except an entry naming one by `id` with `adopt: true`, which takes it over. Every monitor is saved, or none. FILE monitors refuse hand edits other than alert settings, mute and delete (`monitor.managed_by_file.unprocessable`). One sync per organization at a time (`monitors.sync_busy.unprocessable` while another runs). Left-out fields take the defaults of a new monitor, except `locations`, which keep the monitor's locations. Alert policies and status page components are set with `PUT /v1/alert-policies/{policyId}/monitors` and `PUT /v1/status-pages/monitors/{monitorId}/components`.