TLS certificate check

What it verifies

Each region opens a direct TLS handshake to the host and port, sends the host name as SNI, and reads the leaf certificate. The check passes when the handshake validates against the public root store, the certificate has not expired, and the issuer and the subject common name match any patterns you set. Inside the warning window, the result carries an advisory, and owners and admins get an hourly email and in-app notice. Only a failed check changes the state: an expired certificate, a rejected handshake, a pattern that does not match, or a host that does not resolve.

Use it when

• A host serves TLS without an HTTP endpoint worth asserting on, or the certificate needs its own monitor, history, and incident.
• The certificate must come from a specific issuer or carry a specific subject, for example after a CA change or a move to a new name.
• The people who renew the certificate should hear about expiry in advance. From 14 days before the end by default, the result carries an advisory and an hourly email goes out.

The check reads only the leaf certificate, with no OCSP, no CRL, and no cipher grading. For STARTTLS ports, such as SMTP on 587 or IMAP on 143, use the SMTP or IMAP check with its certificate sub-check, because this check handshakes directly. An https URL you already monitor can carry the same policy as a sub-check of the HTTP(S) check.

Swipe sideways to inspect the product view.

app.perstat.io

Configuration

Target. A host name or IP address without scheme, path, or spaces (labels up to 63 characters, 253 in total), plus an optional port from 1 to 65535. Without a port, the handshake goes to 443. The probe resolves the host through its own resolver and sends it as SNI on every handshake. Loopback, private, link-local, and cloud metadata addresses are refused like other reserved ranges, so the monitor cannot reach an internal network.

IP families

The handshake runs over IPv4 by default. With both families, every resolved address of each family gets its own handshake. The result keeps one sub-result per family and per address, so an IPv6-only failure is visible as such. The form offers IPv6 only when the host has an AAAA record or is an IPv6 literal, and then only regions that probe IPv6 stay selectable.

How a check runs

1. Each region due for the interval starts the check, which times out after 10 s. It compiles the issuer and subject patterns first, and an invalid pattern ends the check as an error before any network access.
2. The node’s own resolver resolves the host. Every resolved address of the chosen family is validated against the blocked ranges.
3. Every address gets its own TLS handshake with the host name as SNI. Validation uses the public root store, or an accepting verifier when allow_self_signed is on. The leaf certificate is read from the handshake.
4. Common name, alternative names, issuer, and validity are parsed. Every pattern you set must match, and expiry is judged to the second against the certificate’s end date.
5. The certificate is kept with the result for display. Once the remaining lifetime is below warn_days, the advisory is attached. The control plane turns it into an hourly email and in-app notice for owners and admins, and the state stays unchanged.
6. The region’s result goes to the control plane. The alert policy decides when failing regions open an incident, by default once 2 regions agree over 2 consecutive checks.

Swipe sideways to inspect the product view.

app.perstat.io

What a result contains

Certificate

The result keeps the common name, alternative names, and issuer, plus validity from and until with the days left. It records whether the certificate is self-signed and publicly trusted (public_trusted, shown as publicly trusted in the monitor view). Once the warning window is reached, it also carries the advisory.

Detail line

One line with the common name, the issuer, and the days left, or a note that the certificate has expired. With allow_self_signed on, the line starts by saying whether a self-signed or an untrusted certificate was accepted.

Response time

None for this type. The check judges the certificate, not the handshake speed, so no response time is recorded or shown.

Cause layer

Whether the failure sat with the target’s DNS (NXDOMAIN or NODATA) or with the target itself after the name resolved. Anything else is reported as unknown.

Region, family, address

Every result carries the region that measured it, and one sub-result per IP family and per address.

States and severity

• okThe handshake is accepted, the certificate is still valid, and the issuer and subject patterns match. A certificate inside its warning window keeps this state.
• degradedThis state comes only from folding several results at the default family_fail_severity. One IP family fails while the other answers, or some of several resolved addresses fail. The certificate check itself has no degraded outcome.
• downThe handshake is rejected because of an untrusted chain, a hostname mismatch, or expiry in strict mode. The check is also down past the end date, on a pattern mismatch, with no certificate served, or when the host does not resolve or resolves to a blocked address. With family_fail_severity: failed, one failing family also counts as down.
• errorThe check cannot be evaluated because an issuer or subject pattern is invalid or the served certificate cannot be parsed. It counts as an outage with severity critical.

Confirmed by quorum: by default, 2 regions must report the failure before an incident opens. The organization default asks for 2 regions and 2 consecutive checks. A monitor can carry its own rule with count or percent, consecutive checks, and a minimum duration.

Plans and limits

Shortest interval

300 s on Free, 60 s on Pulse, 30 s on Sentinel, 15 s on Command, and 10 s on Enterprise. The web form offers 30 s, 1 min, 5 min, 15 min, and 1 h. The 15 s and 10 s floors are reachable only through MCP.

Regions

2 of 6 on Free, 3 of 6 on Pulse, and all 6 from Sentinel.

Monitors

10 on Free, 50 on Pulse, 150 on Sentinel, 500 on Command, and a custom quota on Enterprise. The eleven probe types share this quota. Host agents and heartbeats have their own quotas.

Compare every plan limit

From the pipeline or an agent

The same config works in the deploy step, in an MCP client such as Claude Code, and in the form above. create_monitor needs an organization-wide API key. If you omit regions, the plan picks its default.

{
  "name": "Storefront certificate",
  "type": "ssl_cert",
  "interval_seconds": 900,
  "config": {
    "host": "example.com",
    "port": 443,
    "warn_days": 21,
    "issuer_regex": "Let's Encrypt",
    "subject_regex": "example\\.com"
  }
}

Every interface, with its boundary

Limits

• Only the leaf certificate is judged. The chain is reported only as publicly trusted or not.
• No OCSP, no CRL, and no cipher grading.
• Direct handshake only, no STARTTLS. For SMTP on 587 or IMAP on 143, use the SMTP or IMAP check with its certificate sub-check.
• No response time is recorded for this type. Uptime and the certificate carry the result.
• The warning window never changes the monitor state. Expiry does.
• Targets on private, loopback, link-local, and cloud metadata addresses are refused.
• Not every region probes IPv6, so selecting ipv6 restricts the usable regions.

Related check types

• HTTP(S) checkAvailability and response of a URL, with assertions on status, body, and TLS.
• SMTP checkBanner and EHLO of a mail server, with an optional certificate check over STARTTLS or implicit TLS.
• IMAP checkReachability of an IMAP server through its greeting, on 993 after a TLS handshake, with an optional certificate policy.
• Domain checkDelegation across every authoritative nameserver, registration expiry, and DNSSEC of a registrable domain.

All check types