Monitors Beta
Create, read, change, pause and delete uptime monitors. These are the monitors on the Uptime page in the app, and every change you make here shows up there straight away.
Every endpoint in this group needs an X-API-Key header, and each call counts once against your daily quota. Reading needs access to uptime monitoring in the app; every other method needs permission to manage uptime monitors. See Monitoring API: getting started for authentication, rate limits and errors.
Endpoints
| Method | Endpoint | Does |
|---|---|---|
GET | /api/v1/monitors | List monitors, filtered by status, active, tags or a text search |
POST | /api/v1/monitors | Create a monitor and run a first check |
GET | /api/v1/monitors/{id} | One monitor with uptime, last outage, certificate, domain, maintenance and settings |
PATCH | /api/v1/monitors/{id} | Change a monitor, sending only what differs |
POST | /api/v1/monitors/{id}/pause | Pause a monitor, and resume it again |
DELETE | /api/v1/monitors/{id} | Delete a monitor and its history |
PATCH | /api/v1/monitors | Pause, resume or re-time up to 500 monitors at once |
DELETE | /api/v1/monitors?ids=… | Delete up to 500 monitors at once |
GET | /api/v1/monitors/options | The allowed values and defaults for every setting |
The monitor settings reference covers every field you can send. For the raw checks a monitor has run, see Results; for uptime figures, see Reports.
How checks work
Each monitor is an HTTP check of one URL. A 2xx or 3xx response counts as up, as long as the page also passes any text checks you set. Checks run every intervalMinutes, from the locations in regions; with more than one location, they take turns.
A scheduled check that fails is retried up to twice more, four seconds apart, before the monitor counts as down, so a one-off blip doesn't raise a false alarm. The first check when you create a monitor or change its URL is a single attempt, so the status shows straight away.
status is up, down or pending (not checked yet).