Step 01
Define
Calls, workflows, schedules, alerts, projects, and members live as YAML or JSON on disk. The schema is documented and validates on save.
Configuration as Code
Monitoring lives in your repo versioned, reviewed, rolled back.
Write and maintain your application monitoring in a single human-readable YAML or JSON file. Calls, workflows, schedules, alerts, projects, and members are defined as code, reviewed in PRs, and shipped on the same release pipeline as the APIs they watch.
YAML / JSONGit-nativePR reviewGitHub Actions / GitLab / JenkinsAudit-grade history
~/acme/monitoring/maincommit
9f7c2a1parsing / 0%1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# monitors/payments.create.yaml
name: "payments.create"
path: "POST /v1/payments"
regions:
payments.create
v2.41.0POST /v1/paymentsawaiting config...awaiting config...awaiting config...awaiting config...100%of platform exposed as config
YAML / JSONhuman-readable / machine-applicable
Git-nativebranches / PRs / rollbacks
<2sfrom commit to live monitor
How it works
Edit a file, open a PR, ship the monitor same loop as your code.
Pull the project, change the YAML in the editor you already use, push it back. Reviewers approve in GitHub. The platform applies it the moment main moves.
Step 02
Review
Open a PR like any other. Diffs show exactly what's changing: thresholds, regions, headers, owners, and release gates.
Step 03
Apply
When the PR merges, the platform reconciles in under two seconds. Roll back any change with a git revert.
Make API monitoring part of your development process
Edit application monitoring as part of every API change.
Drop the monitoring repo into the same workspace as the APIs it watches. When an engineer changes an endpoint, they change the monitor in the same PR, and the same reviewers approve both.
Single source of truth: /monitoring next to the API code
Calls, workflows, schedules, alerts, projects: all as files
Drop into existing CI: GitHub Actions, GitLab CI, CircleCI, Jenkins
Validate locally with --dry-run before opening a PR
project / acme/monitoring4 changes pending
acme/monitoring
git / main / 9f7c2a1calls
24 / 2 modifiedpayments.create.yaml
Maccounts.list.yaml
auth.token.yaml
Mworkflows
7 / 1 addedcheckout.flow.yaml
refund.flow.yaml
+schedules
14alerts
11 / 1 modifiedp95.rule.yaml
Mproject.yaml
members.yaml
Calls24
Workflows7
Schedules14
Alerts11
Version control your monitoring
Every change tracked. Every change reversible.
Git, or any version control system, gives you change tracking, code review, and rollbacks for free. See exactly what every commit moved: a threshold, a region, an owner, and revert any one of them with a one-line PR.
Diffs that read like spec changes, not screenshots
Branches and PRs for every meaningful change
Roll back a threshold, an alert, or an entire project in seconds
Tag a release and pin monitoring to the same SHA as the API
monitors/payments.create.yamlPR #481 / 3 reviewers+5 -2
1 name: "payments.create"
2 path: "POST /v1/payments"
3 regions:
4 - aws-us-east-1
5-- gcp-eu-west-2
6+- gcp-eu-west-2
7+- azure-ap-south
8 schedule: every 60s
9 assert:
10-p95_ms: 600
11+p95_ms: 500
12 status: 201
13+alert:
14+channel: "#payments-prod"
15+on: 3-of-5 fail
Manage your full monitoring program
Calls, workflows, schedules, projects, members: one apply.
Configuration as code is not just for monitors. Update schedules across the fleet, change alerting thresholds, rotate credentials, add team members, fork projects, and let the platform reconcile the approved diff.
Bulk-update schedules and thresholds across hundreds of monitors
Rotate service tokens and revoke access without leaving the repo
Project lifecycle: create, fork, archive, transfer as code
Members and roles: scope, deploy permission, alert routing
apictx apply ./monitoring183 changes / 1.4s
x142scheduleevery 60s -> every 30s