Documentation
Complete guide to setting up website monitoring with PingZen. API documentation, code examples, and best practices.
An TLS/SSL monitor opens a TLS connection to a host and port, reads the certificate the server presents, and warns you before it expires. It sends no application data — no HTTP request, no mail command — so it works on any service that serves TLS from the first byte.
Certificates are not an HTTP thing. The same certificate with the same expiry date sits in front of mail (SMTPS on 465, IMAPS on 993), directories (LDAPS on 636), message brokers (AMQPS on 5671), IoT (MQTTS on 8883), caches and databases over TLS (Redis on 6380), gRPC, secure WebSockets and any binary protocol of your own. The handshake is the same for all of them, which is why one monitor type covers them all.
A note on the name. SSL itself is long gone: SSLv3 was deprecated in 2015, and what actually runs today is TLS 1.2 or TLS 1.3. The certificates never changed name in common usage, so certificate authorities still sell “SSL certificates” and every monitoring tool still has an SSL check. That is why the monitor is called TLS/SSL both in the app and here — TLS first because that is what actually runs on the wire, SSL second because that is still the word people search for. Everywhere the distinction matters, this page says TLS.
TLS/SSL Monitor or HTTPS Monitor?
Both watch the certificate, and they answer different questions. An HTTPS monitor takes the expiry date off the same connection it uses to check the site, and sends the “Certificate Expiring” alert itself once the certificate is inside the critical window. A TLS/SSL monitor speaks no application protocol at all, so it reaches services no HTTP request can, and it records the whole certificate rather than just its dates. Running both on one host is no longer required — if the second monitor exists only for the countdown, you can delete it and get the plan slot back. Here is what each one gives you, and when you want the TLS/SSL monitor anyway.
A website: both warn you, in different ways
The HTTPS monitor stays green and sends a "Certificate Expiring" alert inside the critical window, 7 days by default — the status does not change, no incident opens, no uptime is lost. The TLS/SSL monitor turns amber earlier, at 14 days, can send a "Degraded" alert on that step, and records the issuer, subject, SAN list, TLS version and cipher on every check. From the certificate an HTTPS monitor keeps three values only: issued, expires, and days left.
Mail, directories, brokers, IoT — anything that is not the web
After the handshake an HTTPS monitor has to send an HTTP request, so pointed at an LDAPS, AMQPS or MQTTS port it stays permanently red no matter how healthy the certificate is. The TLS/SSL monitor sends nothing — it finishes the handshake, reads the certificate and closes the connection. For everything that is not a web server it is the only option there is.
A certificate somebody else renews
A partner API, a payment gateway, a CDN, a storefront on someone else's domain. The renewal notice from their registrar goes to them and the outage lands on you. A monitor pointed at their host is the only warning you are going to get. If it is an ordinary website, an HTTPS monitor is enough; the TLS/SSL monitor is what you need when their entry point does not speak HTTP or sits on a non-standard port.
The full list of services and ports the TLS/SSL monitor works with is in the next section.
Services It Works With
The TLS/SSL monitor works with any service that starts TLS immediately on connect, on any port:
| Service | Typical address |
|---|---|
| HTTPS on a non-standard port | example.com:8443 |
| SMTPS (mail submission over implicit TLS) | mail.example.com:465 |
| LDAPS | ldap.example.com:636 |
| AMQPS (RabbitMQ) | mq.example.com:5671 |
| MQTTS | iot.example.com:8883 |
| Redis over TLS | cache.example.com:6380 |
| Secure WebSocket, gRPC over TLS, or a custom binary protocol | api.example.com:8443 |
The monitor never speaks the protocol behind the port — it only completes the handshake and reads the certificate. That is why one monitor type covers all of them.
Services It Does Not Work With
Some services do not serve TLS from the first byte. They start in plain text, and the client asks to upgrade with a command like STARTTLS. The TLS/SSL monitor cannot read those certificates: it tries to start TLS immediately while the server is still speaking plain text. Almost all of them have a sibling port that serves TLS straight away — point the monitor at that one instead.
| Not supported | Why | What to use instead |
|---|---|---|
| SMTP on ports 587 and 25 | Plain text first, then STARTTLS | Port 465 — it is the same certificate |
| IMAP on 143 | Plain text first, then STARTTLS | Port 993 — and no second monitor needed, an IMAP monitor on 993 reads the certificate itself and sends "Certificate expiring" |
| POP3 on 110 | Plain text first, then STARTTLS | Port 995 |
| Explicit FTPS on port 21 | Plain text first, then AUTH TLS | Port 990 |
| PostgreSQL, MySQL, RDP | TLS is negotiated inside the protocol's own startup exchange | Nothing — they have no port that serves TLS straight away |
If a service has no immediate-TLS port at all, PingZen currently has nothing that can alert on its certificate expiry. An SMTP monitor on 587 confirms that STARTTLS is still offered and the server answers, but it does not show the certificate dates.
What It Checks
On every check the TLS/SSL monitor reads the certificate and verifies it:
- Days until expiry — from the certificate’s
notAfterdate - Certificate lifetime —
notAfterminusnotBefore, used to scale the thresholds (see below) - Chain validity — the certificate must be signed by a trusted authority
- Hostname match — the host you monitor must be covered by the certificate’s SAN list
- Issuer, subject and SAN list — shown on the monitor page
- TLS version and cipher suite — recorded with every check
Expiry is the reason most people add this monitor, but the chain and hostname checks run every time too. A certificate that is valid for another 60 days but signed by an authority your visitors do not trust still fails the check.
Expiry Thresholds
Two settings control when the monitor reacts:
Expiry Warning (days) — default 14
Inside this window the monitor turns amber (degraded). Uptime is not affected — the service still works, it just needs attention.
Expiry Critical (days) — default 7
Inside this window the monitor also sends a "Certificate Expiring" alert, at most once every 24 hours, to every alert subscribed to that trigger.
The default is 14 days, not 30, because Let’s Encrypt renews a 90-day certificate when 30 days are left. A 30-day warning would fire on every healthy renewal.
The amber state and the alert are two different things. The monitor turns amber as soon as the warning window starts, but the email or Telegram message only arrives inside the critical window. An amber badge without a message is expected, not a bug.
The Certificate Lifetime Cap
Certificate lifetimes are shrinking. Let’s Encrypt issues 6-day certificates today, and the CA/Browser Forum has voted to cut the maximum to 47 days by 2029. A fixed “warn 7 days before expiry” would keep a 6-day certificate permanently in the critical window.
So PingZen caps both thresholds by the certificate’s own lifetime:
- the warning threshold never exceeds one third of the lifetime
- the critical threshold never exceeds one sixth of the lifetime
The cap only lowers your setting, never raises it. With the defaults of 14 and 7, the cap does nothing until a certificate is shorter than 42 days.
| Certificate lifetime | Warning at | Critical at |
|---|---|---|
| 90 days (Let's Encrypt standard) | 14 days | 7 days |
| 45 days | 14 days | 7 days |
| 30 days | 10 days | 5 days |
| 12 days | 4 days | 2 days |
| 6 days (Let's Encrypt short-lived) | 2 days | 1 day |
The cap is applied silently: the monitor colours the days-left badge by the capped values, but the numbers you see in the form stay the ones you set. If a server does not send a usable issue date, the cap is switched off and your raw settings apply.
What Each Status Means
| Situation | Status | What you get |
|---|---|---|
| Outside both windows | UP | Days remaining shown on the monitor |
| Inside the warning window | DEGRADED | Amber badge, "Degraded" alert on entering. No incident, no uptime loss |
| Inside the critical window | DEGRADED | Same amber badge plus a "Certificate Expiring" alert, at most once per 24 hours |
| Certificate has expired | DOWN | Incident opens, down alert fires |
| Incomplete chain (missing intermediate) | DEGRADED | Browsers accept it, other clients may not. Fix by serving the full chain |
| Self-signed, untrusted issuer or wrong hostname | DOWN | Certificate details are still shown, so you can see what was served |
Configuration
Address
A hostname, a hostname with a port, or a full URL. The scheme and path are stripped, so pasting a browser URL works. Without a port, 443 is used. Examples: example.com, example.com:8443, https://example.com/login
Expiry Warning (days)
When the monitor turns amber. Default 14, range 1 to 365. Capped at one third of the certificate lifetime.
Expiry Critical (days)
When alerts start. Default 7, range 1 to 30, and never above the warning value. Capped at one sixth of the certificate lifetime.
Check interval
Default 6 hours. Certificates change rarely, so there is no reason to check them every minute.
Alerts
To be notified, attach an alert with the Certificate Expiring trigger. Add the Degraded trigger too if you want to hear about the earlier amber stage as well.
Certificate alerts have their own 24-hour cooldown, separate from down alerts, so a certificate reminder can never suppress a real outage message.
Key Features
- Reads the certificate without sending any application data, so it works on any TLS port
- Warning and critical thresholds that adapt to short-lived certificates automatically
- Checks chain validity and hostname match on every run, not just the expiry date
- Shows issuer, subject, SAN list, TLS version and cipher suite
- Shows certificate details even when validation fails, so you can see what the server actually served
- Degraded state costs no uptime — an expiring certificate is a warning, not an outage
Common Questions
What protocols can I monitor?
PingZen supports 23 protocols: HTTP/HTTPS, WebSocket (WS/WSS), TCP, UDP, ICMP Ping, gRPC, DNS, WHOIS, TLS/SSL certificates, Email (SMTP/IMAP/POP3), FTP/FTPS, DNSBL, PageSpeed, SOCKS5, MTProxy, API Check, and Transaction. You can monitor websites, APIs, servers, databases, and any network service.
How fast can I get alerts?
Telegram alerts are delivered within 1-2 seconds of detection. Slack and Discord notifications arrive almost instantly. You can configure multiple alert channels for redundancy.
Can I organize monitors by project?
Yes! PingZen supports workspaces, which let you organize monitors by project, environment, or team. Each workspace can have its own alert configurations and team members.
Is there an API for automation?
Absolutely. PingZen provides a full REST API with OpenAPI documentation. You can create, update, and delete monitors programmatically.
How do status pages work?
Status pages are public, branded pages showing your services' uptime. You can display real-time status and allow customers to subscribe for updates.
What happens if I reach my monitor limit?
We'll notify you when approaching your limit. You can pause some monitors or contact us for increased capacity. We never stop monitoring without warning, ensuring your critical services stay protected.
Ready to stop missing downtime?
Join thousands of teams who trust PingZen. Setup takes 30 seconds.