Overview
Create a monitor that checks an endpoint, server or scheduled job on a fixed interval. Six monitor types are supported:HTTP, KEYWORD, ICMP (ping), TCP (port), DNS and HEARTBEAT. Checking starts as soon as the monitor is created.
Authentication
Creating a monitor also requires a verified email address on the account that owns the key (otherwise
EMAIL_NOT_VERIFIED, 403) and a role that can create monitors (otherwise INSUFFICIENT_PERMISSIONS, 403).
Request body
Common fields
Probe locations
UptimeIO checks from multiple locations (see Probe locations). Themonitoring_regions values you can send are listed by the public GET /api/regions endpoint.
- Use
[]to let UptimeIO pick among the available locations. This is the only option on the Free plan. - Pro and Scale can pin regular checks to one or more locations. At least one location is enough.
- A region group code (
europe,north-america,asia,oceania) selects every location in that group.GET /api/regionsneeds no authentication. - A location with no active probe is rejected with
INVALID_REGIONS. - An incident is only opened after failures are confirmed from more than one location. The confirming checks use other locations automatically, so selecting a single location does not weaken that protection.
HTTP monitor
Check a URL and expect a status code.http_config fields:
Keyword monitor
Fetch a URL and check the response for words that must, or must not, be present.keyword_config fields:
Set request headers, body, redirect handling and expected status codes for a keyword monitor through
http_config (same fields as above).
ICMP (ping) monitor
TCP (port) monitor
DNS monitor
Heartbeat monitor
UptimeIO waits for your job to ping a generated URL.target is not needed.
The response contains
heartbeat_token. Your job pings the URL /heartbeat/{heartbeat_token}; the full ping URL, including host, is shown on the monitor in the dashboard. See Heartbeat monitors.
SSL certificate monitoring
Applies toHTTP and KEYWORD monitors on https:// targets.
Domain expiry monitoring
Warns you before the registration of the monitored domain expires.
How it works:
- Registration data is looked up via RDAP and refreshed hourly; it is not re-read on every check.
- Only
HTTP,KEYWORDandDNSmonitors whose target is a publicly registered domain qualify. IP addresses,localhostand internal names (for exampledb.internal) are rejected withVALIDATION_ERROR(400), withdetails.fieldset todomain_monitoring. - The registered domain is what is checked:
https://api.eu.example.co.uk/healthis checked asexample.co.uk, and a hosted subdomain such asmyapp.herokuapp.comasherokuapp.com. - Some country-code registries do not publish an expiry date (many
.dedomains, for example). For those the expiry is reported as not published and no warnings are sent.
Response
201 Created
keyword_config, tcp_config, dns_config, icmp_config, ssl_monitoring, domain_monitoring, heartbeat_token). created_at and updated_at are Unix timestamps in seconds. monitoring_regions and tags are accepted when you write a monitor but are not included in monitor responses. See Get Monitor for the full field list.
Plan limits
Errors
Errors use the standard envelope (see Errors).
Targets are rejected when they point at private or reserved IP ranges,
localhost and *.local, *.internal, *.lan names, well-known third-party domains, or the apex of example.com, example.org, example.net and test.com for HTTP and KEYWORD monitors. Subdomains such as api.example.com are allowed.