Monitoring that lives in your repoWhere 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.
$ 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 completeHow it works
Define monitors in YAML
Add yorker.config.yaml to your repo alongside app code. Define monitors, assertions, locations, and alert rules in plain YAML.
yorker deploy computes the diff
CLI compares your local config against remote state. Creates, updates, and deletes monitors to match your config exactly.
Review the plan, apply when ready
Use --dry-run to preview changes before applying. The plan output shows exactly what will change.
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.
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"]# 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 completeTerraform-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
CI/CD integration
yorker validate in CI returns zero exit on valid config — 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.
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 — 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.
Close your observability blind spot
Free tier includes 10,000 HTTP checks and 1,500 browser checks per month. No credit card required.
npx yorker init