MetriBeacon
Menu
Websites & APIs

SSL Certificate Monitoring: Track HTTPS Expiry with MetriBeacon

Monitor the certificate your website actually serves. Set expiry alerts, check renewal and recognise missing data with MetriBeacon.

Subscribe via RSS
In this article

An expired HTTPS certificate can stop visitors from reaching a website even while the server is running. Automatic renewal reduces that risk, but a failed renewal or an old certificate still being served can go unnoticed. SSL certificate monitoring checks what your public endpoint actually presents and gives you time to act before expiry.

With MetriBeacon, an HTTP monitor records certificate days remaining alongside availability, response time and HTTP status. This guide explains how to choose the right URL, set an expiry alert and distinguish a fresh certificate measurement from missing data. For a broader introduction, see our website monitoring guide.

Why monitor SSL certificates when renewal is automatic?

An ACME client or hosting provider handles issuance and renewal. Monitoring answers a different question: is the certificate visitors receive still valid, and how much time remains?

A renewal process may fail because a validation challenge cannot complete. It may also succeed while a proxy keeps serving the previous certificate. An external check helps you notice that gap between issuing a certificate and deploying it to the endpoint.

“SSL certificate” is the familiar search term; modern HTTPS uses TLS. MDN explains TLS and server authentication: a certificate binds the server's key to its domain name. A valid TLS connection does not prove that login, checkout or every API operation works. Monitor the relevant HTTP response as well.

Choose the HTTPS hostname your visitors use

Start with the exact public address, such as https://example.org/. This is a placeholder: replace it with your own website. Avoid a plain HTTP starting address when your main goal is certificate monitoring.

Check which endpoints matter to your users:

  • The main domain and a separately used www hostname.
  • An API hostname reached directly by clients.
  • Other public HTTPS services with their own certificates or deployment paths.

A redirect does not make all certificates interchangeable. MetriBeacon records the certificate days from the first successfully checked HTTPS response in the redirect chain. One monitor therefore does not provide a separate expiry measurement for every later hostname. Create distinct monitors for important endpoints whose certificate lifetime you need to track independently.

With a CDN or reverse proxy, the public check observes the certificate presented at that public endpoint. It does not inspect a separate certificate on the origin server behind it. MetriBeacon's HTTP checks support public addresses on ports 80 and 443; private-network targets are outside this monitor's scope.

Set up SSL certificate monitoring in MetriBeacon

You do not need to install an agent on the website's server for this HTTP check.

  1. Open Monitors, choose your workspace and select Add monitor → Website or API.
  2. Enter a clear name and the public HTTPS URL.
  3. Choose GET or HEAD and the HTTP status you expect. Use GET if you also need a text or supported JSON-value check.
  4. Choose a check interval. The default is five minutes; the supported range is one to 60 minutes.
  5. Save the monitor and wait for its first result.
  6. Open the monitor's series and inspect certificate days remaining, the measurement time and availability. Configure an alarm separately to receive notifications.

The remaining lifetime is recorded in whole days. Treat it as planning lead time, not a second-by-second expiry deadline. A number without a recent observation is not evidence that the current certificate is healthy. The HTTP monitor documentation covers configuration and result states.

Set expiry alerts with time to respond

Choose a threshold that leaves enough time to investigate, renew and deploy. Do not copy a warning period without considering the certificate's lifetime, your renewal schedule and who can respond.

MetriBeacon's suggested certificate rule triggers below 14 days and clears above 21 days. These are starting values for that suggested rule, not a universal renewal policy. You can adjust numeric rules. For example, a team might use a warning below 14 days and a separate critical rule below seven days. A short-lived certificate may need substantially different values.

The gap between trigger and clear thresholds is hysteresis: it keeps an incident from repeatedly opening and closing near the same boundary. Make the clear threshold achievable after a successful renewal. Use the latest value when you want to check the currently observed remaining lifetime, and keep any required duration consistent with the check interval.

An alert also needs a destination:

  • Create and confirm an email destination, or connect a private Telegram chat.
  • Send a test notification to verify the connection.
  • Select that destination in the certificate rule and enable the rule.
  • Decide who handles the warning and how reminders should work.

See numeric rules and hysteresis and email and Telegram setup. Creating a monitor alone does not subscribe you to expiry messages.

Missing certificate data is not an all-clear

Certificate days require a successful observation of a certificate. If TLS verification fails before a response is available, a new certificate-days measurement may be absent. An expired or invalid certificate is not automatically represented by a fresh zero-day value.

Look at the latest observation time, availability and diagnostic details together. DNS problems, network errors, paused checks or exhausted budgets can also leave gaps. Unknown means the target state could not be determined reliably; it is not proof of a confirmed website outage or of healthy HTTPS.

A numeric expiry rule does not substitute for monitoring missing data. Add an appropriate missing-data rule for the certificate series if you need a warning when fresh observations stop. Allow for the expected interval and planned maintenance. Monitor availability separately so a website failure is visible even when no new expiry value arrives.

Verify that renewal reaches the public endpoint

MetriBeacon observes certificate lifetime; it does not renew or install certificates for you. Keep automated renewal in your hosting platform or ACME tooling.

Let's Encrypt's integration guide recommends using ACME Renewal Information to choose renewal timing and automating renewal. Your monitoring warning should leave room to recover from failures before expiry, rather than replacing that process. Do not assume every certificate has the same lifetime.

After a warning, check renewal logs and the responsible hosting configuration. When renewal succeeds, verify the externally observed result:

  1. Wait for a fresh MetriBeacon check; do not judge success from an old chart value.
  2. Confirm that remaining days increase to the expected new lifetime.
  3. Confirm that the HTTPS request and expected HTTP response still work.
  4. Check separately monitored hostnames, proxies or CDN endpoints that may deploy certificates independently.
  5. Confirm that the rule clears after its configured condition is met.

If your own renewal script runs as a scheduled job, cron job monitoring can complement the public certificate check. A successful job result and a fresh endpoint measurement provide different evidence.

A practical SSL monitoring checklist

Keep the first setup focused on one important public endpoint, then extend it where certificates or deployment paths differ.

  • The monitor starts with the HTTPS hostname visitors actually use.
  • Certificate days and their observation time are visible.
  • The expiry threshold matches renewal timing and response capacity.
  • A confirmed notification destination is selected and tested.
  • Availability and missing observations have their own appropriate rules.
  • Someone is responsible for renewal failures and deployment checks.
  • A fresh result verifies that the renewed certificate is being served.

MetriBeacon is free within the documented monitoring quotas. HTTP checks and notifications use available account budgets, so include those limits when choosing intervals and the number of endpoints.

Frequently asked questions about SSL certificate monitoring

Can I monitor SSL certificates for free with MetriBeacon?

Yes. HTTPS certificate days are part of the HTTP monitor, within the documented account quotas. Create a monitor for a public HTTPS URL and configure a separate alarm for the remaining lifetime.

Does MetriBeacon renew my SSL certificate automatically?

No. Renewal and installation remain with your hosting provider or ACME client. MetriBeacon checks the public endpoint and can notify you through a configured rule and destination.

Does one monitor cover every subdomain and redirect?

No. The monitor records one certificate-days series from the first successfully checked HTTPS response. Add separate monitors for important HTTPS hostnames when you need independent expiry measurements.

Why is there no current certificate-days value?

A failed TLS connection or another check interruption may prevent a fresh measurement. Inspect timestamps and diagnostics, and use a missing-data rule instead of interpreting absent data as zero or as a healthy certificate.

How many days before expiry should I receive a warning?

There is no single safe threshold for every certificate. Choose it around the actual lifetime, automated renewal timing and response time. The suggested rule's 14-day warning is editable; shorter-lived certificates need an appropriate smaller window and earlier operational follow-up.

Ready to start? Create your MetriBeacon account, or use the button below to open the Website or API template and add your first HTTPS monitor.