What is an HTTPS Check?
An HTTPS check is an HTTP uptime check that runs over TLS. Xitoring's probing nodes establish a real TLS handshake, validate the certificate chain, and then perform the same status-code, keyword, and response-time validation as a plain HTTP check.
This is the recommended check type for any production web service — it catches both application-layer failures (5xx, slow responses) and transport-layer failures (expired cert, broken chain, weak ciphers).
For ongoing certificate-expiry tracking with grading and OCSP, also enable SSL certificate monitoring on the same domain.
What Gets Monitored
- TLS handshake success — connection negotiates without errors
- HTTP status code — 2xx, 3xx, 4xx, 5xx
- Response time — total request duration including handshake
- Response body content — keyword presence/absence
- Certificate validity — expired, self-signed, or hostname mismatch is flagged
- Redirect chains — followed or treated as a failure
- Geographic latency — performance from each probing node
Prerequisites
- A publicly reachable HTTPS URL (e.g.,
https://example.com/health) - A valid TLS certificate trusted by standard root stores, or the option to disable strict SSL validation if you use an internal CA
- Endpoint allows traffic from Xitoring's probing IP ranges
How to Set Up an HTTPS Check
Step 1: Create the Check
- Log in to your Xitoring Dashboard
- Go to Uptime → Add Check
- Select HTTPS as the check type
Step 2: Configure the Request
- Enter the full URL including
https://(e.g.,https://example.com/health) - Choose the HTTP method (GET, POST, PUT, HEAD, etc.)
- Set the check interval (30 seconds to 15 minutes)
- Set the timeout (default: 30 seconds)
Step 3: Configure Validation
- Expected status code — default
200 - Keyword check — assert a substring exists (or doesn't exist) in the response body
- Custom headers — add auth tokens, API keys, or custom
User-Agent - Request body — for POST/PUT, send JSON or form data
- SSL verification — keep enabled for public endpoints. Disable only for internal CAs
Step 4: Choose Probing Nodes
Select at least 3 nodes across regions. Geographic diversity catches CDN edge issues and regional routing problems.
Step 5: Assign Notifications
Under Triggers, attach a notification role for alerts.
Step 6: Save and Verify
Save the check. The first probe runs immediately.
Setting Up Triggers
Common alerting rules:
- TLS handshake failure — certificate expired, hostname mismatch, or chain broken
- Status code mismatch — response differs from expected
- Keyword missing — required text not found in response body
- Slow response — response time exceeds your SLA threshold
- Down — confirmed failures across multiple probing nodes
Tips
- Always enable SSL verification on public-facing checks — disabling it defeats the purpose of HTTPS monitoring
- Pair HTTPS uptime with SSL certificate monitoring — uptime catches the moment a cert breaks, SSL monitoring warns you 30/14/7 days before
- Watch for redirect loops — set a max redirect depth or treat unexpected redirects as failures
- Pin a specific keyword like
"status":"ok"to confirm the response body, not just the status code - For mTLS endpoints that require client certificates, use a dedicated check type or contact support