---
title: 'Monitoring as Code'
description: 'Define monitors in plain YAML. Deploy with yorker deploy. Terraform-style plan/apply. Git-native, CI/CD-ready synthetic monitoring.'
canonical_url: 'https://yorkermonitoring.com/features/monitoring-as-code'
---

# Monitoring that lives in your repo

**Where it belongs**

Plain YAML. Terraform-style plan/apply. Version-controlled, CI/CD-ready. If you're running a serious operation in 2026, this is table stakes, and Yorker ships it.

```text
$ yorker deploy

Yorker deploy plan for "my-app"

  Checks:
    + CREATE  http     "API Health"       (60s, 3 loc)
    + CREATE  http     "Payment API"     (60s, 3 loc)
    ~ UPDATE  browser  "Checkout Flow"   frequency: 5m→2m
    - DELETE  http     "Legacy Health"   (removed)

  Alerts:
    + CREATE  "API Health:alert:0"
    + CREATE  "Payment API:alert:0"

  Summary: 3 to create, 1 to update, 1 to delete

  ✓ Deploy complete
```

[Start Free](/sign-up) or [Read Docs](/docs).

## How it works

### 01. Define monitors in YAML

Add `yorker.config.yaml` to your repo alongside app code. Define monitors, assertions, locations, and alert rules in plain YAML.

### 02. yorker deploy computes the diff

CLI compares your local config against remote state. Creates, updates, and deletes monitors to match your config exactly.

### 03. Review the plan, apply when ready

Use `--dry-run` to preview changes before applying. The plan output shows exactly what will change.

### 04. Monitors running

Monitors active, running from your configured locations at your configured frequency. Results flowing into your OTel backend.

## Plain YAML, not a DSL

Every engineer already knows YAML. Reviewable in a pull request. Diffable in your terminal. No proprietary language to learn, no SDK to install, no special editor plugin required.

AI coding assistants speak fluent YAML. Create and manage monitors the same way they manage your Terraform or Kubernetes config. Describe the monitor you want, get YAML back, commit it.

```yaml
project: my-app

alertChannels:
  ops-slack:
    type: slack
    webhookUrl: "{{secrets.SLACK_WEBHOOK}}"

monitors:
  - name: API Health
    type: http
    url: https://api.example.com/health
    frequency: 1m
    locations: [us-east, eu-west, ap-southeast]
    assertions:
      - type: status_code
        value: 200
    alerts:
      - conditions:
          - type: multi_location_failure
            minLocations: 2
        channels: ["@ops-slack"]
```

## Terraform-style workflow

`--dry-run` to preview. `--prune` to clean up orphaned monitors. The diff output shows creates, updates, and deletes, before they happen.

- Preview changes with `--dry-run` before applying
- Clean up orphaned monitors with `--prune`
- Validate config in CI with `yorker validate`
- Secrets stay in env vars, never in your repo
- Idempotent: safe to run on every deploy

```bash
# Preview before applying
$ yorker deploy --dry-run

  Summary: 2 to create, 0 to update, 0 to delete
  (dry run: no changes applied)

# Apply the changes
$ yorker deploy

  ✓ API Health created
  ✓ Checkout Flow created

# Clean up orphaned monitors
$ yorker deploy --prune

    - DELETE  http  "old-monitor" (not in config)
  ✓ Prune complete
```

## CI/CD integration

`yorker validate` in CI returns zero exit on valid config, so you can block merges on invalid monitor definitions. `yorker test` runs a single check on demand to verify a new monitor works before it goes live.

AI coding assistants understand YAML config natively. Describe a monitor, get valid config back, run `yorker validate`, commit.

```yaml
name: Monitors
on:
  push:
    branches: [main]
  pull_request:

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx yorker validate

  deploy:
    needs: validate
    if: github.ref == "refs/heads/main"
    steps:
      - run: npx yorker deploy
        env:
          YORKER_API_KEY: ${{ secrets.YORKER_API_KEY }}
```

## Unlike UI-only monitoring tools

- Dashboard-click monitoring isn't reviewable, isn't version-controlled, and breaks down at scale. YAML config means your monitoring is auditable and deployable like any other piece of infrastructure.
- `yorker deploy` computes a diff, so you see exactly what will change before it changes. No surprise monitor deletions, no silent configuration drift.
- AI coding assistants speak fluent YAML. Create and manage monitors the same way they manage your Terraform or Kubernetes config: describe the monitor, get config back, validate, commit.

## Related features

- **[API Monitoring](/features/api-monitoring)**: Unlimited HTTP checks deployed and managed via YAML config.
- **[Browser Monitoring](/features/browser-monitoring)**: Playwright scripts version-controlled alongside your app code.
- **[Private Locations](/features/private-locations)**: Deploy private location runners alongside your monitoring config.

## Frequently asked questions

### Do I need to learn a proprietary language or install an SDK?

No. Monitors are defined in plain YAML, which every engineer already knows. It's reviewable in a pull request and diffable in your terminal. There's no proprietary language to learn, no SDK to install, and no special editor plugin required.

### How does deploy decide what to change?

`yorker deploy` compares your local config against remote state and computes a diff. It creates, updates, and deletes monitors to match your config exactly. The plan output shows precisely what will change before it changes, so there are no surprise monitor deletions and no silent configuration drift.

### Can I preview changes before they're applied?

Yes. Run `yorker deploy --dry-run` to preview the plan without applying any changes. The output shows the summary of creates, updates, and deletes so you can review before you apply.

### What happens to monitors that are no longer in my config?

Use `yorker deploy --prune` to clean up orphaned monitors that are no longer present in your config. Deploys are idempotent, so the command is safe to run on every deploy.

### How does this fit into CI/CD?

`yorker validate` returns a zero exit code on valid config, so you can block merges on invalid monitor definitions. `yorker test` runs a single check on demand to verify a new monitor works before it goes live. You can wire both into a workflow that validates on every push and pull request and deploys on merges to main.

### Where do secrets live?

Secrets stay in environment variables, never in your repo. The config references them (for example, a Slack webhook URL via `{{secrets.SLACK_WEBHOOK}}`), and CI injects API keys from your secret store.

### Can AI coding assistants work with this?

Yes. AI coding assistants speak fluent YAML and understand the config natively. Describe the monitor you want, get valid config back, run `yorker validate`, and commit. It's the same workflow they already use for your Terraform or Kubernetes config.

### Where do monitoring results go?

Monitors run from your configured locations at your configured frequency, with results flowing into your OTel backend.

## Put your first check live in one command.

Free tier includes 10,000 HTTP + MCP checks and 1,500 browser checks per month. No credit card required.

[Start Free](/sign-up) or [Read Docs](/docs).

```bash
npx @yorker/cli init
```