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
x11alertp95 threshold 600 -> 500ms
x24region+ azure-ap-south
x3headerIdempotency-Key required
x2member+ payments-team / deploy
x1projectrotate service token
Ship to production on your release pipeline
Edit to live monitor in minutes, not the next maintenance window.
The same pipeline that ships your APIs ships their monitors. Validation runs in CI, reviewers approve in the same PR, and the apply happens the moment main moves.
Validation, linting, and planning all run in CI
Required reviewers and branch protections fully respected
Deploy via GitHub Actions, GitLab CI, Jenkins, or any runner
Every apply signed so auditors can trace any monitor to a commit
Pipeline / feat/raise-p95-thresholdedit to live in 13m 22s
shippeddeveloper / push branch--
github-actions / validate8s
github-actions / plan3s
review / 3 approvers12m
merge / main--
apictx / apply1.4s
Why configuration as code
Monitoring earns its place in the same workflow as your APIs.
Files, not clicks
Calls, workflows, schedules, and alerts are YAML on disk. Review in PRs, version with your APIs, roll back with git.
Git-native rollback
Every change is a commit. Reverting a regression is one PR, not a support ticket, and it lands in seconds.
First-class CI
Drops into GitHub Actions, GitLab CI, CircleCI, and Jenkins as a single command with machine-friendly diffs.
Members as code
Roles, scopes, and project membership live in files. Granting deploy access is a PR with a clear approver.
Audit-grade history
Every apply is signed and immutable. Auditors trace any threshold, owner, or routing rule back to the commit that set it.
Templates and forks
Spin up a new monitored project from a template, fork an existing one, or import an OpenAPI spec from a single file.
Drops into the pipelines, repos, and editors your team already runs
GitHubGitLabJenkinsCircleCIBitbucketVS CodeJetBrainsSlackPagerDutyDatadog
Ready to start monitoring?
Sign up now and start using the product immediately. Free 14-day trial, no credit card required.