Uptime checks
Every other tab is passive: it reports what happened to real traffic. Uptime is active. It calls your endpoints on a schedule and tells you they're down before a customer does.
Creating a check
Open the Uptime tab and add a check with a name and a URL. It runs with the settings below.
NametextrequiredWhat it's called in the list and on your status page, up to 200 characters.
URLURLrequiredWhat to call, starting http:// or https://. The request carries no credentials, so check an address that answers without them.
MethodchoiceThe HTTP method.
IntervalminutesHow often it runs, from 1 minute to 24 hours.
TimeoutsecondsHow long it waits before it fails, from 1 to 60 seconds.
Max statusstatus codeThe check fails on this status or any above it. A check generated from your spec uses 500, so a 401 still counts as up.
Max latencymillisecondsWhen set, a slower answer fails too.
Enabledon or offPause a check from the list without deleting it.
Generate from your spec
Rather than adding one check per endpoint by hand, generate them from your OpenAPI spec. You get one check for each GET endpoint that takes no required parameters and isn't deprecated, up to 50, named after its path, such as GET /users.
They call the address you give, or your spec's first server, without credentials, so they pass on anything below 500: a 401 still proves the endpoint is up and routing. Generated checks are marked as such, and when your spec changes they follow it, adding checks for new endpoints and removing those for endpoints that are gone. Checks you added yourself are never touched.
Generating gives you coverage in one click. The useful next step is deleting the checks you don't care about: every check is a request against your API, on an interval, forever.
Up and down
A check passes when the answer comes back below Max status, and under Max latency if one is set. A timeout or a connection that fails counts as down.
Changes stream to the dashboard live, so a check going down appears without a refresh. Results are kept for 30 days.
Running one now
Each check has a Run action that fires it immediately instead of waiting for the next interval. Use it after adding a check rather than watching the clock.
Every run is recorded, so a check has a history you can scroll: what it returned, how long it took, and when it flipped up or down.
What to check
A check with a body pointed at a write endpoint writes, every interval, forever. Point checks at read-only or purpose-built endpoints.
Credentials you put in Headers are stored with the check, so use a scoped, revocable one rather than an admin token.
Public status page
Your checks can power a public status page, with the incidents and announcements you post, and a notice on your docs while checks are failing. See status page.
From the CLI
Checks can be generated from your spec and run with octri monitoring checks. Incidents and announcements can be posted with octri monitoring incidents and octri monitoring announcements.