GuidesUptime and SSL monitoring

Website uptime and SSL certificate expiry monitoring

Updated 17 October 2026 · 9 minute read

Website uptime monitoring means testing your site from outside on a fixed schedule and alerting when it stops answering correctly. A good setup checks more than "is it up": it checks the status code, the content and the response time, watches DNS and open ports, and warns you weeks before a TLS certificate expires. To avoid false alarms, it alerts only after repeated failures.

This guide covers each kind of check, sensible settings, the commands to test by hand, and the maths behind uptime percentages.

What synthetic checks are

A synthetic check, or uptime check, is a scripted request that a monitoring system sends to your service on a schedule, whether or not real users are active.

Synthetic checks catch problems at 4 a.m. when nobody is using the site, and they test things users cannot see, such as a certificate that expires next month. They do not tell you what real visitors experience on their own devices; that is the job of real user monitoring, covered below.

The four checks worth having

HTTP(S) checks

The most important check. Request a URL and verify:

• Status code — usually 200. Decide whether redirects (301, 302) count as success.
• Response text — a word or phrase that only appears when the page really works, such as the product name in the footer or "status":"ok" in a health endpoint. Many outages return 200 with an error page, so a status code alone is not enough.
• Latency — how long the full response took. Alert when it stays slow, not only when it fails.

Check the pages that make money or matter most: the home page, login, checkout, and a health endpoint for each API.

TCP port checks

A TCP check opens a connection to a host and port and reports whether it succeeded and how long it took. Use it for services that do not speak HTTP: databases on 5432 or 3306, mail servers on 25 or 587, SSH on 22, message brokers and custom protocols.

DNS record checks

If DNS breaks, everything behind it looks down. A DNS check resolves a name and compares the answer with the value you expect. Watch A and AAAA records for your main hosts, CNAME records pointing at a CDN or load balancer, MX records for mail, TXT records used for email authentication and domain verification, and NS records for the domain itself.

TLS certificate expiry checks

An SSL certificate expiry check connects over TLS, reads the certificate and reports how many days are left. It should also fail if the certificate is invalid: wrong host name, incomplete chain or already expired.

Why certificates still expire with automation

Automated renewal is the right approach, but certificates still expire:

• The renewal job fails silently: a DNS API key was rotated, port 80 was closed, or rate limits were hit.
• The new certificate was issued but the web server, proxy or Java keystore was never reloaded.
• The certificate lives somewhere the automation does not reach: a load balancer, CDN, mail server, appliance or an old host nobody remembers.
• Lifetimes are getting shorter. The maximum lifetime for public certificates fell to 200 days in March 2026 and is planned to fall in steps to 47 days by 2029, so renewals happen more often and every weak spot gets tested more often.

How far ahead to warn depends on the lifetime. For one-year or 200-day certificates renewed by hand, warn at 30 days and again at 14 and 7. For 90-day certificates that automation renews about 30 days before expiry, a warning at 20 days or less means renewal has failed; that leaves time to fix it.

To read a certificate's expiry date by hand:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

The output looks like notAfter=Jan 14 23:59:59 2027 GMT. The -servername option matters: without it, servers that host many sites may return a different certificate. To fail a script when fewer than 30 days remain, replace -enddate with -checkend 2592000 (30 days in seconds); it exits with status 1 if the certificate expires within that time.

Measuring response time by hand

curl can break a request into phases, which helps when a check reports that a site is slow:

curl -o /dev/null -s -w 'dns:        %{time_namelookup}\nconnect:    %{time_connect}\ntls:        %{time_appconnect}\nfirst byte: %{time_starttransfer}\ntotal:      %{time_total}\nstatus:     %{http_code}\n' https://example.com/

Each time is in seconds from the start of the request, so the phases add up. A large gap between tls and first byte points at the server or application; a slow dns or connect points at the network or the resolver.

Check frequency and avoiding false alarms

Most teams check important endpoints every 1 to 5 minutes and less critical ones every 10 to 15. Certificate and DNS checks can run less often, since they change slowly.

A single failed request can be a dropped packet, a network fault near the checker or a restarting instance. To keep alerts trustworthy:

• Alert after repeated failures. Two or three consecutive failures is a common choice. With 1-minute checks, that still pages you within a few minutes.
• Check from more than one location where you can, and alert when several fail. One failing location usually means a network problem near that location, not an outage.
• Set sensible timeouts. A 10-second timeout on a page that normally answers in 300 ms is generous enough to avoid false failures and short enough to catch real ones.
• Silence checks during planned maintenance, so expected downtime does not page anyone.

Monitoring internal and private endpoints

Intranet sites, internal APIs, admin panels and databases are not reachable from the public internet, so an external checker cannot test them. The usual answer is a checker that runs inside your network, often called a private location: a small agent on a server you already own runs the checks and sends the results out.

Uptime percentage maths

Uptime is the share of time, or of checks, in which the service worked. Over a 30-day month of 43,200 minutes:

Two things to keep in mind. Your check interval limits precision: with 5-minute checks, a 2-minute outage may be missed entirely. And uptime measured by checks is not the same as an error budget based on real requests; for that, see our guide to SLOs and burn rate alerts.

Real user monitoring is the complement

Synthetic checks tell you whether the site works from a known place with a known request. Real user monitoring (RUM) measures what visitors actually experience in their browsers: page load times, Core Web Vitals and JavaScript errors, on their devices and networks. Use both: synthetic checks for availability and early warning, RUM for real experience.

Uptime and certificate checks in Televane

Televane synthetic monitoring runs the four kinds of checks described in this guide:

• HTTP(S) with expected status codes and text in the response; TCP port reachability; DNS A, AAAA, CNAME, MX, TXT and NS records with expected values; and TLS certificate validity with a warning a set number of days before expiry.
• Checks run every 1 to 60 minutes, with a run-now button, and alert after repeated failures.
• Private locations: any server running the Televane agent can run checks inside your network, for intranet pages, internal APIs and database ports. The agent connects outbound only.
• Results are kept for 30 days, with uptime and latency.
• Alerts go through the same alerting and on-call as everything else, with silences for maintenance windows. Checks can also be managed as code with obsctl.

For the browser side, Televane real user monitoring adds Core Web Vitals and JavaScript errors from real visitors with one script tag. The Free plan includes 5 synthetic checks, Pro 50 and Business 500; see pricing. You can start free with a 14-day Pro trial.

Frequently asked questions