An SSL/TLS failure means Uptime Basics could not establish a trusted HTTPS connection to the monitored hostname. The web server may be running, but visitors that enforce normal certificate validation can still be unable to use it securely.
This is an availability failure and normally has no HTTP status code because the TLS connection must succeed before an HTTP response can be received.
What the availability check validates
For an https:// monitor, the connection uses the hostname from the URL for Server Name Indication and normal certificate verification. Common failures include:
- an expired or not-yet-valid certificate;
- a certificate that does not cover the monitored hostname;
- an incomplete or untrusted certificate chain;
- a server presenting the wrong certificate;
- unsupported TLS protocol or cipher configuration;
- a failed TLS handshake;
- a CDN, load balancer, or origin with inconsistent certificate configuration; or
- DNS directing some regions to a server with a different certificate.
Accepted HTTP status codes cannot make an invalid TLS connection successful because no HTTP response exists yet.
Check the exact hostname and path
Certificate names apply to hostnames, not only registered domains. A certificate for example.com does not automatically cover www.example.com or app.example.com unless those names are included or matched by an appropriate wildcard.
Also check redirect destinations. The original hostname can have a valid certificate while the HTTPS destination in a redirect has an expired, mismatched, or incomplete certificate.
Troubleshooting steps
- Open Monitor Details and copy the exact HTTPS URL.
- Review Failure Diagnosis and the newest Detailed Logs row.
- Inspect the certificate served for that exact hostname from an external certificate-testing tool.
- Confirm the certificate's start date, expiry date, covered names, issuer, and full chain.
- Verify the web server, CDN, and load balancer all present the intended certificate.
- Confirm every public DNS address for the hostname has consistent TLS configuration.
- Test each redirected hostname.
- Review regional Confirmation for location-specific failures.
Do not rely only on a browser that already has an intermediate certificate cached. An incomplete chain can work on one device and fail for a fresh client.
Common fixes
Expired or not-yet-valid certificate
Renew or reissue the certificate and confirm the server is using it. Check the server clock if a newly installed certificate appears not yet valid.
Hostname mismatch
Issue a certificate containing the exact hostname, then attach it to the correct virtual host, CDN distribution, or load balancer listener.
Incomplete chain
Install the server certificate together with the required intermediate certificates in the correct order. Do not serve the root certificate as a substitute for the intermediate chain.
Wrong certificate on one address
Check every origin, load balancer, CDN edge configuration, and DNS address. Remove stale infrastructure or update it to use the same valid certificate.
Unsupported TLS configuration
Enable current broadly supported TLS versions and secure cipher suites. Avoid obsolete protocol-only configurations. Confirm the server handles SNI for the monitored hostname.
Availability failures versus SSL expiry monitoring
An HTTPS availability check verifies whether a trusted TLS connection can be established during every scheduled availability request.
Optional SSL certificate expiry monitoring is separate. It runs approximately once every 24 hours and warns at the selected 30-, 14-, or 7-day threshold before expiry. It can help prevent an outage, but enabling it does not change how availability checks classify a current TLS failure.
After installing a fix
Confirm the new certificate is served publicly, not only installed in a control panel. DNS, CDN, and load-balancer changes can take time to reach every location.
A successful availability cycle can resolve the outage, and the dashboard can take one additional refresh to show the recovery. Keep the existing monitor so its incident history remains intact.
When to contact Support
Contact Support if independent external TLS tests show a valid certificate and complete chain for every public address, but monitoring continues to report an SSL/TLS failure.
Include the monitor name, HTTPS URL, failed timestamps, certificate issuer and expiry date, and regional Confirmation summary. Never send certificate private keys, account passwords, verification codes, or secret request headers.