SSL Monitoring
TLS handshake and certificate expiry checks against a hostname. Pro and above.
Overview#
An SSL monitor (kind ssl) connects to a hostname (default port 443), inspects the presented certificate, and evaluates validity and days until expiry. Health contributors use observed handshake and expiry data only.
Set up, step by step#
Step 1: Create an HTTP monitor first
On Free and Pro, creating an HTTP monitor also schedules a daily certificate check for that hostname (expiry warnings at 30, 14, and 7 days). Use Monitoring → Add monitor.
Step 2: Read SSL results
After the daily check runs, certificate validity and days-until-expiry appear with the monitor's linked results. Failed handshakes and certificates inside the warn window can open alerts.
Step 3: Standalone SSL rules
A dedicated SSL monitor kind can also be configured when your plan and catalog allow it — see Configuration below. Linked daily checks from HTTP monitors cover the usual Free path without a second form.
Configuration#
hostname— public hostname (SSRF-safe).port— default443.warnDays— warn when the certificate expires within this many days (default30, max 365).
Results#
Failed handshakes, invalid chains, and certificates inside the warn window contribute to project health and can open alerts. Continuous execution requires Trigger workers (overview).
Plans#
Free and Pro run a daily SSL check for the hostname of each active HTTP monitor — no separate monitor needed. Standalone SSL monitors (ssl_monitor) aren’t part of the Free or Pro package; existing Team and Enterprise contracts keep them.
Limitations
- Does not replace certificate management or ACME automation.
- Private or blocked hostnames are rejected before the probe runs.
- No check history until the scheduler (Trigger) has executed the rule.