Monitors
A monitor is a configured request that APIContext runs on your behalf from remote cloud locations around the world. Each monitor defines what to call, how to call it, and what a correct response looks like. When a monitor runs, APIContext records the full result — HTTP status, latency breakdown, headers, and body — so you can track health over time.
Three types of monitor
APIContext supports three monitor surfaces:
| Type | What it tests |
|---|---|
| API monitor | A single HTTP request (any method) against a REST, GraphQL, or SOAP endpoint |
| Browser monitor | A headless browser session that loads a page and captures Core Web Vitals and rendering performance |
| MCP monitor | A request to an MCP (Model Context Protocol) server, testing AI infrastructure availability and correctness |
All three types share the same scheduling, alerting, and results infrastructure. You can mix them freely within a project and combine them into workflows to test multi-step business processes.
How monitors fit together
Monitors are the atomic unit of observability in APIContext. Everything else builds on them:
- Schedules control when and where monitors run
- Conditions define what counts as a pass, warning, or failure
- Alerts notify you when a condition is triggered
- Results store the outcome of every execution
A monitor on its own is a definition. It only produces data when you run it manually or attach it to a schedule.
See also
- Monitor your first API — end-to-end tutorial from creating a project to reading results
- Add a monitor — detailed guide to creating each monitor type
- Browser monitors — setting up browser monitoring
- MCP monitors — monitoring MCP servers