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)

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

Create an HTTP monitor

1. Enter the URL

   Enter the Website URL, including https:// or http://. The Monitor Name is optional and defaults to a name generated from the URL.

2. Set how often to check

   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.

3. 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.

4. Configure the request

   Open HTTP Configuration to set the method, expected status, headers, body and timeout.

5. Attach notification channels

   Choose where alerts go. See Notifications.

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 <base64 of user:password>.

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.

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 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.

Unexpected status code

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.

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 under Advanced Options; do not do this in production.

Cannot choose probe locations or a short interval

Choosing locations and intervals under 5 minutes requires Pro or Scale. See Plans.

Next steps

Keyword Monitoring

Check page content as well

Notifications

Configure alerts for HTTP monitors