Two different failure modes
Uptime monitoring asks whether a public URL responds the way you expect. SSL monitoring asks whether the certificate that URL presents is still valid for visitors, and how long that certificate stays valid.
Those are not the same check. A host can be up while every browser shows a security warning. A certificate can be valid while the application returns 503. Treating “HTTPS responds” as proof that the certificate is fine is how teams miss expiry until a customer sends a screenshot.
What uptime monitoring covers
An uptime check requests your URL on a schedule from outside the server. It looks for a healthy response: the connection succeeds, and the status code is acceptable within a timeout.
Typical causes it catches:
- The server or host is down
- DNS no longer points where you expect
- The app or proxy returns 5xx
- The request times out
The point of the check is time to detection. You learn the page stopped answering without waiting for support mail or a drop in traffic. For more on that alert path, see website down email alerts.
Uptime alone does not answer “when does this certificate expire?” Many monitors also accept HTTPS responses even when certificate validation would fail for a careful client, or they treat TLS as a transport detail rather than a dated asset. The dashboard can look green while visitors cannot get past the browser warning.
What SSL monitoring covers
SSL monitoring reads the certificate the public endpoint serves. The most useful daily question is simple: what is the end date, and is it close enough that you should renew now?
Related certificate problems include a name that does not match the hostname, a chain clients will not trust, or a handshake that fails. Expiry is the failure that arrives on a calendar. How to check when an SSL certificate expires shows a one-off browser or OpenSSL read. Monitoring is that read on a schedule, before the expiry warning replaces your page.
Automatic renewal is not a substitute for this check. Renewal can fail quietly after a DNS change, a missing challenge, or a panel migration. The public certificate is what visitors and APIs see. That is what to verify.
Side by side
| Question | Uptime monitoring | SSL monitoring |
|---|---|---|
| Is the URL answering? | Yes | No |
| Will browsers trust the certificate today? | Not the focus | Yes |
| How many days until expiry? | Usually no | Yes |
| Did the host or app crash? | Yes | No |
| Did auto-renewal leave an old certificate live? | Often missed | Caught when the end date is near or past |
A site can be down with a valid certificate. A site can be up with an expired certificate. Neither green light covers the other failure.
What to watch on a simple public site
For a marketing site, a shop, or a few campaign URLs, start with the addresses people actually open. For each HTTPS URL, you want two signals: whether the page responds, and how long the current certificate remains valid.
You do not need an enterprise APM stack for that. You need an external check that does not depend on a process running on the same host that just failed.
SiteOK checks each URL you add every 30 minutes for a healthy response, and for HTTPS it also reads the certificate expiry date. The mobile dashboard shows up, down, or SSL warning. Email alerts fire when a page stops responding. The weekly email includes SSL expiry for each URL. Seven days of check history stay on the detail screen. Nothing is installed on your server.
Start a free trial with a public URL. No signup is required.