HTTP/HTTPS Monitoring

An HTTP monitor sends an HTTP or HTTPS request to your URL on a schedule and checks the response status code and response time. Use it for websites, REST APIs, login endpoints and any other web service.

When to use it

Website or API availability and response time
Health-check endpoints (/health)
Web services that need custom headers, a request body or a specific status code
Tracking SSL certificate and domain expiry for a site (see below)

To also check the page content, use a Keyword monitor.

Create an HTTP monitor

Set the basics

Enter a name and the URL to monitor, then choose the check interval and timeout.

Choose probe locations

UptimeIO checks from multiple probe locations. On Pro and Scale you can choose which locations run your regular checks (at least one). On Free, locations are selected automatically.

Configure the request

Set the method, headers, body and expected status codes (see below).

Attach notification channels

Choose where alerts go. See Notifications.

Settings

Field (API)	Description	Default
`name`	Monitor name, up to 80 characters	Required
`type`	`HTTP`	Required
`target`	URL (or hostname) to check. Only `http://` and `https://` are accepted	Required
`interval_seconds`	Time between checks, 30 to 86,400. Your plan sets the minimum: 300 on Free, 60 on Pro and Scale	Required
`timeout_ms`	Maximum wait for a response, 1,000 to 60,000. Must be shorter than the check interval.	`10000`
`monitoring_regions`	Probe locations. `[]` means automatic. Free must send `[]`	Required
`http_config.method`	`GET`, `POST`, `PUT`, `DELETE`, `HEAD`, `OPTIONS`, `PATCH`	Required inside `http_config`
`http_config.headers`	Request headers (object of strings)	none
`http_config.body`	Request body for `POST`, `PUT`, `PATCH`	none
`http_config.expected_status_codes`	List of status codes that count as success, each 100 to 599	`[200]`
`http_config.follow_redirects`	Follow redirects	`true`
`http_config.max_redirects`	Maximum redirects to follow, 0 to 10	`5`
`http_config.slow_response_threshold_ms`	Slow-response threshold (see below)	none
`verify_ssl`	Verify the server certificate. With `true`, an invalid or expired certificate fails the check	`true`
`ssl_monitoring`	SSL certificate monitoring (see below)	off
`domain_monitoring`	Domain expiry monitoring (see below)	off

Targets that are private or internal are rejected with a VALIDATION_ERROR: localhost, private IP ranges (10.x, 172.16-31.x, 192.168.x, 127.x and similar), and names ending in .local, .internal or .lan. UptimeIO’s own domains and test domains such as example.com are rejected too.

Example

curl -X POST https://api.uptimeio.com/api/monitors \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production API health",
    "type": "HTTP",
    "target": "https://api.yourcompany.com/health",
    "interval_seconds": 300,
    "timeout_ms": 10000,
    "monitoring_regions": [],
    "http_config": {
      "method": "GET",
      "headers": { "Accept": "application/json" },
      "expected_status_codes": [200]
    }
  }'

An API key needs the read_write scope. See Create Monitor for the full request and response.

Status codes and redirects

A check succeeds only when the response status is in expected_status_codes. If you do not set it, only 200 counts as success. Set the list explicitly for other codes, for example [200, 201, 204]. Ranges are not supported; list each code.

`follow_redirects`	Behavior
`true` (default)	Follows up to `max_redirects` redirects and checks the final response.
`false`	Checks the first response. A `301` or `302` fails unless it is in `expected_status_codes`, which is how you detect an unexpected redirect.

Authentication

Send credentials as request headers:

"headers": { "Authorization": "Bearer YOUR_TOKEN" }

"headers": { "X-API-Key": "YOUR_SERVICE_KEY" }

The http_config.auth object (basic / digest) is accepted by the API but is not applied to checks. Send a Basic credential yourself in an Authorization header instead. Use a dedicated, revocable credential for monitoring.

Slow response alerts

Set http_config.slow_response_threshold_ms to open a separate slow response incident when a check takes longer than the threshold. It resolves when the response time stays below 80% of the threshold for 3 consecutive checks. A monitor can be up and still have an open slow-response incident.

SSL certificate monitoring

Turn on ssl_monitoring for HTTPS targets to track certificate health.

"ssl_monitoring": {
  "enabled": true,
  "check_expiry": true,
  "check_validity": true,
  "expiry_warning_days": [30, 15, 7, 1],
  "ignore_self_signed": false
}

Field	Description	Default
`enabled`	Turn SSL monitoring on	Required
`check_expiry`	Warn before the certificate expires	`true`
`check_validity`	Detect invalid certificates	`true`
`expiry_warning_days`	Days before expiry to warn. Only `30`, `15`, `7` and `1` are allowed, at least one when `check_expiry` is on	`[7, 1]`
`ignore_self_signed`	Do not treat self-signed certificates as invalid	unset

What happens:

Warnings: at each selected threshold (30, 15, 7 or 1 days before expiry) a warning is sent to the monitor’s notification channels. Warnings do not open an incident, because the site is still up.
Expired or invalid certificate: opens an incident, which resolves automatically once a valid certificate is served.

Domain expiry monitoring

Turn on domain_monitoring to be warned before the domain registration runs out.

"domain_monitoring": { "enabled": true, "expiry_warning_days": [30, 15, 7, 1] }

Available for HTTP, Keyword and DNS monitors.
The target must be on a publicly registered domain. IP addresses, localhost and internal names are rejected with a VALIDATION_ERROR.
UptimeIO looks up the registration through RDAP (the registry lookup protocol) and evaluates warnings every hour against the stored expiry date.
Warnings go to the monitor’s notification channels at 30, 15, 7 and 1 days (only the values you select; all four by default). They do not open an incident.
Subdomains are checked against their registrable domain: app.example.com is checked as example.com. A subdomain of a shared platform domain such as myapp.vercel.app is checked against the platform’s domain, not yours.
Some country-code registries do not publish an expiry date. Those domains show as not published and never produce warnings.

GET /api/monitors/{id}/domain-info returns domain, status, expires_at, days_until_expiry and registrar.

Response time breakdown

Each check records DNS, TCP connect, TLS handshake, time to first byte (shown as Server) and total time. The monitor page shows the split per location, with the remainder as Transfer. Use it to tell whether slowness comes from DNS, the network, TLS or your application. See Reading metrics.

Best practices

Point the monitor at a lightweight health endpoint that checks your critical dependencies and answers quickly.
Keep the timeout close to what a healthy response needs (5-10 seconds for APIs).
Prefer HEAD when you only need availability and your server answers it correctly.
Expect incidents to open only after confirmation from several probe locations (see Understanding incidents).
Allow the UptimeIO-Monitor/1.0 user agent through your firewall or WAF.

Troubleshooting

Timeout errors

The server was too slow or unreachable. Check the timing breakdown to see which stage is slow, raise timeout_ms (maximum 60,000, and always shorter than the check interval) if the server legitimately needs longer, and make sure a firewall or WAF is not blocking the UptimeIO-Monitor user agent.

Unexpected status code

Only 200 passes by default. Add the codes your endpoint returns to expected_status_codes. If the endpoint redirects, enable follow_redirects or list the redirect code. Check with curl -I https://your-url.

SSL certificate errors

An HTTPS check fails when the certificate is expired, self-signed, has an incomplete chain or does not match the hostname. Fix the certificate, and check that the chain includes intermediate certificates. For a test system with a self-signed certificate you can clear Verify SSL certificate (verify_ssl: false); do not do this in production.

403 LOCATION_MONITORING_NOT_AVAILABLE

You sent a non-empty monitoring_regions on the Free plan. Send [], or upgrade to Pro or Scale to choose locations.

INTERVAL_TOO_SHORT or MONITOR_LIMIT_REACHED

The interval is below your plan minimum, or you reached your plan’s monitor limit. See Plans.

Getting Started

Monitor Types

Essentials

Notifications

Integrations

Status Pages

Account & Team

Plans & Billing

HTTP/HTTPS Monitoring

When to use it

Create an HTTP monitor

Settings

Example

Status codes and redirects

Authentication

Slow response alerts

SSL certificate monitoring

Domain expiry monitoring

Response time breakdown

Best practices

Troubleshooting

Next steps

Keyword Monitoring

Notifications

​When to use it

​Create an HTTP monitor

​Settings

​Example

​Status codes and redirects

​Authentication

​Slow response alerts

​SSL certificate monitoring

​Domain expiry monitoring

​Response time breakdown

​Best practices

​Troubleshooting

​Next steps

Keyword Monitoring

Notifications

When to use it

Create an HTTP monitor

Settings

Example

Status codes and redirects

Authentication

Slow response alerts

SSL certificate monitoring

Domain expiry monitoring

Response time breakdown

Best practices

Troubleshooting

Next steps