> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uptimeio.com/llms.txt
> Use this file to discover all available pages before exploring further.
# HTTP/HTTPS Monitoring
> Check websites, APIs and web services with HTTP/HTTPS requests, plus SSL certificate and domain expiry warnings
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](#ssl-certificate-monitoring))
To also check the page content, use a [Keyword monitor](/monitors/keyword).
## Create an HTTP monitor
Enter a name and the URL to monitor, then choose the check interval and timeout.
UptimeIO checks from multiple [probe locations](/monitors/probe-locations). On **Pro** and **Scale** you can choose which locations run your regular checks (at least one). On **Free**, locations are selected automatically.
Set the method, headers, body and expected status codes (see below).
Choose where alerts go. See [Notifications](/notifications/overview).
### 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
```bash theme={null}
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](/api-reference/monitors/create) 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:
```json theme={null}
"headers": { "Authorization": "Bearer YOUR_TOKEN" }
```
```json theme={null}
"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.
```json theme={null}
"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.
```json theme={null}
"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](/essentials/reading-metrics#timing-breakdown).
## 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](/essentials/understanding-incidents)).
* Allow the `UptimeIO-Monitor/1.0` user agent through your firewall or WAF.
## Troubleshooting
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.
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`.
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.
You sent a non-empty `monitoring_regions` on the Free plan. Send `[]`, or upgrade to Pro or Scale to choose locations.
The interval is below your plan minimum, or you reached your plan's monitor limit. See [Plans](/billing/plans).
## Next steps
Check page content as well
Configure alerts for HTTP monitors
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.