> ## 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 the **Website URL**, including `https://` or `http://`. The **Monitor Name** is optional and defaults to a name generated from the URL.
In **How often we check**, choose the **Check Interval**. The shortest interval depends on your plan: 5 minutes on Free, 1 minute on Pro and Scale.
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.
Open **HTTP Configuration** to set the method, expected status, headers, body and timeout.
Choose where alerts go. See [Notifications](/notifications/overview).
### Settings
| Setting | What it does | Default / options |
| - | - | - |
| **Monitor Name** | Name shown in your dashboard | Generated from the URL, up to 80 characters |
| **Website URL** | The page or endpoint to check. Private and internal addresses are not accepted | Required |
| **Check Interval** | Time between checks | 1, 2, 3, 4, 5, 15, 30 minutes, 1, 6, 12 or 24 hours. Plan minimum applies |
| **Method** | HTTP method for the request | `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD`, `OPTIONS` |
| **Expected Status** | Status codes that count as success. Pick a group (2xx, 3xx, 4xx, 5xx), pick individual codes, or type any code from 100 to 599 and press Enter | `200`. At least one code is required |
| **Timeout** | Longest wait for a response. Must be shorter than the check interval | 30 seconds. Options: 5, 10, 15, 20, 30, 45, 60 seconds |
| **Headers** | Custom request headers. **Common** adds frequently used ones | None |
| **Request body** | Body for `POST`, `PUT` and `PATCH`, up to 10,000 characters | None |
| **Follow redirects** (Advanced Options) | Follow redirects and check the final response | On |
| **Max Redirects** (Advanced Options) | Redirects to follow, 1 to 10 | 5 |
| **Verify SSL certificate** (Advanced Options, HTTPS only) | When on, an invalid or expired certificate fails the check | On |
SSL certificate, domain expiry and slow response alerts are under **SSL, domain & performance alerts** (see below).
### Example
* **Website URL**: `https://api.yourcompany.com/health`
* **Method**: `GET`
* **Expected Status**: `200`
* **Headers**: `Accept: application/json`
* **Check Interval**: 5 minutes
## Status codes and redirects
A check succeeds only when the response status is one of the **Expected Status** codes. By default **only `200` counts as success**. Add other codes explicitly, for example `200`, `201` and `204`. Each code is listed individually.
| Follow redirects | Behavior |
| - | - |
| On (default) | Follows up to **Max Redirects** and checks the final response. |
| Off | Checks the first response. A `301` or `302` fails unless it is in **Expected Status**, which is how you detect an unexpected redirect. |
## Authentication
Send credentials as request **Headers**:
* `Authorization: Bearer YOUR_TOKEN`
* `X-API-Key: YOUR_SERVICE_KEY`
For Basic authentication, send `Authorization: Basic `.
Use a dedicated, revocable credential for monitoring.
## Slow response alerts
Under **SSL, domain & performance alerts**, turn on **Slow Response Alert** and enter a threshold in milliseconds (100 to 30,000). UptimeIO opens 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 Certificate Monitoring** for HTTPS URLs to track certificate health.
| Setting | What it does | Default |
| - | - | - |
| **Check Certificate Expiry** | Warn before the certificate expires | On |
| **Expiry thresholds** | Warn at 30 days, 15 days, 7 days and 1 day before expiry. Select at least one | 7 days and 1 day |
| **Check Certificate Validity** | Detect expired, self-signed or otherwise invalid certificates | On |
What happens:
* **Warnings**: at each selected threshold 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 Expiry Monitoring** to be warned before the domain registration runs out.
* Available for **HTTP, Keyword and DNS** monitors.
* The URL must be on a publicly registered domain. IP addresses, `localhost` and internal names are not accepted.
* Choose the thresholds (30, 15, 7 and 1 days before expiry). All four are selected by default.
* Warnings go to the monitor's notification channels. 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.
## 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 the **Timeout** (maximum 60 seconds, 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**. If the endpoint redirects, turn on **Follow redirects** or add 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** under **Advanced Options**; do not do this in production.
Choosing locations and intervals under 5 minutes requires Pro or Scale. 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.