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:
auth is accepted but is not applied to checks. To send credentials, set an Authorization header in headers instead.

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

Each check sends packet_count echo requests of packet_size bytes, about one second apart, and succeeds if at least one reply is received. Values above the ranges are rejected with a validation error. A check ends at timeout_ms, so keep timeout_ms at least packet_count seconds; packets not yet sent by then are not counted.

TCP (port) monitor

The ssh protocol is a connection test only; its banner is not checked. A check with no data to send and no expected response succeeds as soon as the connection is accepted.

DNS monitor

Validation modes: exact passes when every expected value appears in the resolved values; contains passes when at least one does; regex passes when at least one resolved value matches one of the expected values treated as a regular expression. The monitor succeeds only when all entries pass, and an entry fails when no records of its type exist. For MX records only the mail server hostname is compared, not the priority.

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.

Heartbeat ping endpoint

Pings go to https://heartbeat.uptimeio.com/heartbeat/{token} or the same path on api.uptimeio.com. Both hosts behave identically. The URL needs no authentication; the token is the credential. Send GET or POST. A POST may carry an optional JSON metadata object: up to 10 keys (letters, digits, _, -; 1-100 characters), values that are strings (up to 500 characters), numbers or booleans, about 2 KB in total, with the request body limited to 20 KB. A body that is not valid JSON is ignored and the ping is still recorded. A successful ping returns 200 with { "success": true, "data": { "message": "Heartbeat received", "timestamp": 1790000000000 } }.

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.
  • GET /api/monitors/{id}/domain-info returns domain, status, expires_at, days_until_expiry and registrar for the monitor’s domain.

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