1. Start from what you have, or from the example
With a read_write API key in REALUPTIME_API_KEY, run realuptime export -f realuptime.yaml to write your account's http checks as a file, or copy the example from the docs. Every key is the REST API's own POST /checks field (name, url, intervalSeconds, regions, assertion*): nothing renamed. name is the key each check is matched on, so keep it unique. JSON works too: use a .json extension.
2. Plan before you touch anything
realuptime apply -f realuptime.yaml --dry-run lists the account, diffs by name, and prints a plan: + create, ~ update with per-field diffs, ! replace, - delete, = unchanged, ? notes for checks it leaves alone. It exits 2 when anything would change and 0 when nothing would, so a PR step can fail on drift without applying. realuptime validate -f checks the file offline.
3. Apply, and know what needs a flag
realuptime apply -f realuptime.yaml creates and updates (regions and assertions edit in place). A url or intervalSeconds change has no edit endpoint in the API, so it is a delete-and-recreate the plan labels replace and refuses without --allow-replace. An http check on the account that the file does not name is only deleted with --prune --yes. Heartbeat, TCP, DNS, SMTP and multistep checks are never touched: the API cannot create them.
4. Re-run freely
A second apply against the same file plans zero changes and prints Nothing to apply. On an API refusal the run stops at that step, prints the API's own message and RU- code, and exits 1; the next run recomputes the plan from live state and continues. Today the file declares checks only, because the REST API writes nothing else yet; status pages, components, channels and alert rules arrive in the file when they arrive in the API.
Go deeper
The full reference lives in the docs: Monitoring as code documentation. Error codes named above are each explained in the error-code reference.