Currently the monitors aren’t monitoring for a valid SSL cert for a domain, I believe it’s just looking at expiry date rather than the domains it’s valid for. For example we had a domain with an invalid SSL cert on it as it had a different domain on the cert due to a config error and so the secure connection was rejected via browser but Uptime Robot never flagged the issue and said everything was OK.
Is there any chance of that functionality being added as part of the SSL checks on uptime robot? Just to check that the domain being monitored is on the SSL cert? So that an SSL cert error is triggered if an SSL cert is invalid?
I can confirm this issue. I recently ran into the exact same problem.
The server was returning a certificate issued for a different hostname (the physical server’s default certificate), not for the monitored domain. Both with and without SNI, openssl confirmed the mismatch:
openssl s_client -connect example.com:443 -servername example.com
→ subject=CN = different-server-hostname.example.net
My browser correctly flagged it as a hostname mismatch error, but the UptimeRobot monitor reported the SSL check as valid.
I contacted UptimeRobot support about this and was initially told that hostname validation (CN/SAN matching) is performed as part of the SSL check. However, after escalating to the DEV team, the final response was that this is currently expected behaviour.
This is a real gap: the SSL check passes even when no valid certificate exists for the monitored domain, which is exactly the scenario where an alert would be most useful.