HTTPS monitoring: what to check beyond a 200 OK

You set up an uptime check and it turns green. The site is up. But the certificate expired last week, or the CDN edge in your primary region is down, or the login page is stuck in a redirect loop. A check that only looks for a 200 OK misses the failures that actually take HTTPS sites down.

An HTTPS monitor is an HTTP check plus the TLS layer. It resolves DNS, opens a TCP connection, and validates the certificate before sending the request. A failure at any step is a failed check. Most cheap “uptime” tools skip the first three steps and only look at the status code.

This guide covers what an HTTPS check actually tests, the failure modes a 200-only check misses, how to check an endpoint by hand, and how to configure a monitor that catches them.

What an HTTPS check actually tests

The check runs in a strict sequence:

1. DNS resolves the hostname.
2. TCP connects to port 443.
3. TLS handshake: the server presents a certificate; the client checks the hostname matches (SNI is sent so the right certificate comes back), the chain reaches a trusted root, and the certificate is inside its validity window.
4. HTTP request is sent (method, headers, optional body, optional auth).
5. Response status code is compared with the expected code.
6. Optionally the response body is searched for an expected string.
7. Total time is recorded as response time.

Steps 1-3 are what “HTTPS” adds over plain HTTP. If the certificate is expired, the chain is broken, or the hostname does not match, the handshake fails. The HTTP request never happens and the monitor records a failure.

A monitor that skips certificate validation, or that only asks “did I get a 200”, is testing step 5 alone. Everything below is a failure that lives in the other six steps.

Eight failures a 200-only check misses

Expired or mis-issued certificates. Browsers block pages with expired or invalid certificates. A check that ignores certificate validation still sees a 200 from the server behind them. The site is down for users and up for the monitor.

Wrong hostname on the certificate. The certificate was renewed on www but the apex still serves the old one, or the CDN certificate does not include a subdomain. Browsers refuse the connection; a monitor that does not compare the hostname to the certificate sees nothing wrong.

Incomplete certificate chain. Chrome caches intermediates it has seen before, so a missing intermediate works in the browser. It fails for curl, mobile apps, and monitoring from a clean client. This is the classic “works on my laptop” certificate incident.

Error pages returning 200. Maintenance pages and application errors are often served with a 200. The status matches, so the check passes. Require a string that only appears on the working page, such as a footer build ID or a product name, and the check fails when the page is wrong.

Login redirects. A page that redirects to /login returns a 302. A monitor expecting 200 flags it as a failure and pages someone about a healthy page. Set the expected status code to 302 for login-walled pages.

Redirect loops and downgrades. A loop between two URLs, or a redirect chain that ends on http://, is broken for users. Follow redirects in the check and verify the final status.

Slow responses. A site answering 200 in 8 seconds is “up” and alerts nobody by default. A response-time threshold raises a separate slow alert while the monitor stays OK.

Regional failures. A CDN edge or DNS problem in one region makes the site unreachable from there. A single check location never sees it. Check from more than one location.

Check an HTTPS endpoint by hand

Verify the endpoint from a clean client before configuring the monitor. This confirms the TLS chain, certificate validity, and response behaviour without a browser cache helping.

Status, total time, and TLS verification in one line:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s verify=%{ssl_verify_result}\n' https://example.com/

ssl_verify_result 0 means the certificate verified. Any other number is an OpenSSL error code.

Certificate expiry and subject:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -subject -enddate

Follow redirects and show where the chain ends:

curl -sSL -o /dev/null -w '%{url_effective} %{http_code}\n' https://example.com

The same checks run in a browser from this site: the website check tool shows the status plus a timing breakdown, and the SSL checker shows expiry, chain, and hostname.

How to configure an HTTPS monitor

The field names below are AlertKick’s, from the monitor types reference; the defaults are the ones that ship. Most other tools have the same knobs under different names.

Select the HTTP/HTTPS monitor type and enter the full URL users hit. Do not point the monitor at a load balancer health endpoint; that tells you the balancer is fine, not that the site is.

Set the method to GET by default. HEAD is lighter but some frameworks answer HEAD differently from GET, so GET is the safer choice. POST, PUT, PATCH, DELETE and OPTIONS with a request body and custom headers are there for API endpoints. Basic auth or a bearer token is sent as the Authorization header.

Set the expected status code. It is required. 200 for a public page, 302 for a page that redirects unauthenticated users to login.

Add an expected response string. The check fails unless the body contains it. Only the first 10 KB of the body is inspected, so pick a string near the top of the page: a heading, a product name, a footer build ID that the template renders early.

Turn on certificate expiry monitoring. It is not a separate monitor type; ssl_cert_monitoring is offered automatically for https:// URLs.

Set the check interval. The web form defaults to 60 seconds. The Free plan floor is 300 seconds; Professional and Business go to 60. Values below the plan floor are raised to the floor, not rejected.

Set the timeout. The default is 30 seconds with a range of 1-300. 10 seconds is a better fit for a public site: anything slower than that is already a problem you want counted.

Leave the failure threshold at 3. The monitor turns Critical and alerts after 3 consecutive failed results. Below that it shows Warning and nobody is paged, which is what stops one dropped packet from waking someone.

Enable the response-time threshold. response_time_alert_ms is off by default; 2000 is a reasonable start for a public page. Only successful checks count. A check slower than the threshold adds to a separate slow-check streak, and a failed check clears it because the down alert already owns that case. When the streak reaches the failure threshold a distinct “slow” alert is raised while the monitor status stays OK, and the first crossing writes an event like “Response time 8200ms exceeded threshold 2000ms for 3 consecutive checks”.

Select at least two poller locations. Each location runs its own check on the interval and every result feeds one shared failure counter, so three failures from one location and one failure from each of three locations both trip the default threshold. More locations mean faster and broader coverage, not a vote. Free plans include one regional location. Internal dashboards and private APIs can be checked by running an on-premise poller inside your own network.

Bind an escalation policy. If none is chosen, the account default applies. The policy, not the monitor, decides who is paged.

A successful result from any location resets the counter. A Critical monitor returns to OK and the open alert auto-resolves, so the alert list only shows what is still broken.

Starting values for a public HTTPS site: interval 60 s, timeout 10 s, expected 200, a keyword only the working page shows, failure threshold 3, response-time threshold 2000 ms, two or more locations, certificate expiry monitoring on.

Where HTTPS monitoring stops

An HTTPS monitor sends one request and checks the handshake, the certificate, the status code, an optional string in the body and the response time. It does not verify application logic. A server can be up with a valid certificate while the application behind it returns a blank page or a JavaScript error; the monitor sees a 200 and a healthy handshake. Checking that a user can log in or complete a purchase needs a scripted transaction check, which is a different tool.

It checks the URL you give it and nothing else. A broken page elsewhere on the site, or an origin that is fine while one CDN edge is not, only shows up if a monitor points at that page from that region.

It also does not watch the things around the certificate. Domain registration is a separate check with a much longer lead time; an expired domain takes down the certificate, the site and email together, and recovery takes weeks rather than hours. Set up a domain expiry monitor alongside the HTTPS one, and read how to monitor SSL certificate expiry for the renewal-era failure modes that expiry monitoring is there to catch.

For the full list of outside-in checks a site needs, uptime, content, certificates, domain, response time and heartbeats, see the website monitoring setup guide. The HTTPS monitor is the first of them, and the one most sites already have configured wrong.