API Monitoring
Build a request, define what a passing response looks like, and run it on a schedule from the regions you pick. Assertions on status code, response time, a JSON path, or a header catch a broken endpoint before it becomes a support ticket.
Engineers from these teams use ObserveOne
What it does
The same saved check you send once to test an endpoint is the unit a scheduled, multi-region monitor runs. No separate config to maintain.
Name it, pick a method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), set the URL, headers, and a JSON body with a dedicated editor. Or paste a curl command or a .http file and the method, URL, headers, and body parse straight into the form.
Status code equals 200. Response time under 1000ms. A JSON path matches. A header holds a value. A response body contains a substring. Any failing assertion fails the run, and that is what drives alerting.
Set how often the check runs, then add a retry count and interval so one flaky response does not page you. A run only counts as down after the retries are exhausted.
Pick which regions execute a check and set the request timeout. Multi-region runs show availability and latency from where your users actually are, not just from one location.
View docs →
Bearer, Basic, API key, or OAuth2 client-credentials auth, built from vault references instead of hand-written headers. The vault only ever reads back key names, never values, and secrets are stripped before a request leaves the platform.
View docs →
Group checks under a shared base URL and default headers with a collection. Switch a check between staging and production with an environment. The check's own settings always win over what it inherits.
View docs →Turn on alert-on-failure and pick the channels to notify. Channels are configured once and reused across every check, so wiring a new monitor into your on-call flow is a checkbox, not a new integration.
Any saved check exports as a curl command or a .http file, auth included, secret values stripped and swapped for {{KEY}} placeholders. Reproduce the request elsewhere or commit it next to your code.
Any assertion you define failing on a scheduled run: a status code that does not match, a response slower than your threshold, a missing or wrong JSON field, a missing header, or a body that no longer contains an expected substring. Retries absorb a single flaky response before a run is marked down.
Yes. The Execution tab lets you pick which regions run each check and set the request timeout. Running from more than one region shows you availability and latency from where your users are, not just from one location.
In a per-check secrets vault that is write-only: you can add or overwrite a key's value, but the dashboard only ever reads back key names. Reference a secret anywhere in the URL, headers, or body with {{KEY}} and ObserveOne resolves it server-side at send time. Values never appear in the saved check, in send-now output, or in an export.
No. Paste a curl command or a .http file with Import and the method, URL, headers, and body parse into the form automatically. A saved check also exports back to curl or .http, with secret values stripped.
Bearer token, Basic auth, API key in a header you name, and OAuth2 client-credentials. Each type takes vault references rather than raw values and assembles the correct Authorization header for you.
Yes, with collections and environments. A collection groups checks under a shared base URL and default headers. An environment is a named set of variables and secrets you switch a check between. The check's own settings override anything it inherits from either.
Yes. The ObserveOne CLI (@observeone/cli) can run, schedule, and sync API checks as config as code, and every command supports --json output for scripts and pipelines. See the CLI docs for the full command set.
Start for free
Generate tests, monitor production flows, and catch failures before users report them.
No credit card required · Free plan available · Upgrade anytime