Skip to main content

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). The monitoring_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/regions needs 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 to HTTP 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, KEYWORD and DNS monitors whose target is a publicly registered domain qualify. IP addresses, localhost and internal names (for example db.internal) are rejected with VALIDATION_ERROR (400), with details.field set to domain_monitoring.
  • The registered domain is what is checked: https://api.eu.example.co.uk/health is checked as example.co.uk, and a hosted subdomain such as myapp.herokuapp.com as herokuapp.com.
  • Some country-code registries do not publish an expiry date (many .de domains, for example). For those the expiry is reported as not published and no warnings are sent.

Response

201 Created

The monitor object carries the fields relevant to its type (for example 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.

Example