API monitoring
An endpoint called every minute with the method, headers and body you set, judged on the status and the response, and shown call by call on a public page.
Northwind is up.
The monitor is responding, 3 failed checks in the last 24 hours.
API
Up for 22 h 35 min99.79% passed
1,438 checks, median 204 ms, 3 failed checks
95% under 299 ms
- HTTP 5023 min, 3 checks
How the check works
An API monitor is an HTTP monitor with the request spelled out. Pick the method (GET, HEAD, POST, PUT, PATCH or DELETE), add headers such as Authorization: Bearer ... or an API key, and give it a body. Set the status the endpoint should return, and a keyword the response must contain, such as "ok":true, or must not, such as "error". The call runs every minute on Hobby and Pro, every 5 minutes on Free, with a ten-second timeout, and bodies are read up to one megabyte.
Health endpoints
The simplest monitor is a health endpoint that answers 200 when the service and its dependencies are fine and 503 when they are not. Because StatOSS records the response time of every call, the same monitor also shows the endpoint getting slower before it fails; a slow threshold in milliseconds turns that into a state with its own alert. For a job rather than a service, a heartbeat monitor runs the check the other way round.
When it counts as down
A monitor counts as down after two failed checks in a row and as back after one success. Before a failure counts, it is checked again in the same region; only a failure both checks see goes on the record. On Hobby and Pro every other region checks at the same moment, so the page can say down from North America instead of down. A single failed check still appears on the strip with its time and reason, it just does not change the state or send an alert.
Alerts
Each change of state sends one alert: down, and back, with how long it was out. Email is on every plan. Hobby and Pro add Slack, Discord, Microsoft Teams, Telegram, PagerDuty, Opsgenie, Pushover, ntfy and a signed webhook, plus a repeat notice every so many minutes while an outage lasts. Nothing is sent during a maintenance window.
What the status page shows
Every monitor gets a strip on the public page. Each bar is one check, its height the response time; amber marks a timeout and red any other failure. Consecutive failures are grouped into one entry with the time and the reason, and the mark stays there for the whole range. A monitor going down opens an incident on the page by itself and resolves it on recovery.
Managing monitors from code
Everything the dashboard does is in the REST API: create monitors, open incidents, post updates, and mark deploys so a release shows as a dashed line on the response-time chart. Keys read or write, and reach every page or one. An MCP endpoint exposes the same tools to an agent, and a read-only one sits next to every page with no key at all.