Feature Description
Add SSL/TLS certificate expiry monitoring to LogTide's HTTP/HTTPS monitoring section. When configuring an HTTP/HTTPS check, the user should be able to enable certificate monitoring via a simple checkbox (opt-in per check). Once enabled, the check inspects the endpoint's TLS certificate and raises alerts as the expiry date approaches, at one or more configurable day thresholds. Any number of thresholds should be supported, with sensible defaults of 15, 7, and 3 days before expiry.
Problem/Use Case
Expired TLS certificates are one of the most common and most avoidable causes of outages: browsers hard-fail, APIs stop trusting the endpoint, and clients see security warnings that instantly erode trust. Since HTTP/HTTPS endpoints are already being monitored in LogTide, the certificate is right there on the connection — checking its expiry adds a high-value early-warning signal at almost no extra cost. Multiple escalating reminders (rather than a single alert) ensure the warning isn't missed and give teams a clear runway to renew before the certificate actually lapses. This is especially important when managing many endpoints or client sites, where a single expired cert can take a production service offline.
Proposed Solution
Extend the existing HTTP/HTTPS check with an optional certificate-monitoring feature:
- Enable toggle: a checkbox on the HTTP/HTTPS check to turn on certificate expiry monitoring (off by default, opt-in per check).
- Configurable thresholds: allow an arbitrary list of "days before expiry" values at which to alert. Defaults:
15, 7, 3. Max 3 values.
- Data source: read the certificate directly from the TLS handshake performed during the existing HTTPS check — no extra request or external service needed.
- Alerting: fire through LogTide's existing alert/notification channels, one alert per crossed threshold so escalation is visible.
Alternatives Considered
- Manual tracking (spreadsheets, calendar reminders): error-prone, doesn't scale, and easy to forget.
- Relying on the CA/registrar emails: inconsistent, often sent to a single contact, and impossible to centralize across many endpoints.
- A separate standalone certificate check: works, but duplicates the connection LogTide already makes during the HTTP/HTTPS check — folding it into the existing check is simpler and cheaper.
Implementation Details (Optional)
- Add the feature under the existing HTTP/HTTPS monitoring section so it reuses the same UI, scheduling, and alerting flow.
- Extract the certificate from the TLS handshake already performed by the HTTPS check; read the
notAfter field and compute days_remaining in UTC.
- Support an arbitrary, user-defined list of alert thresholds; default to
[15, 7, 3]. Fire one alert per threshold as it is crossed, ideally de-duplicated so a given threshold only alerts once per certificate lifetime.
- Consider validating the full chain (not just the leaf) and surfacing whether the certificate is already expired or not yet valid.
- Handle endpoints with SNI / multiple certificates gracefully, and treat handshake/lookup failures as a distinct "unknown" state rather than an immediate critical.
Priority
Target Users
Additional Context
Certificate expiry monitoring is a baseline expectation for any HTTP/HTTPS monitoring tool, and integrating it directly into the existing check keeps configuration minimal for the user. The multi-threshold default (15/7/3 days) mirrors common industry practice and gives teams a clear, escalating renewal runway.
Contribution
Feature Description
Add SSL/TLS certificate expiry monitoring to LogTide's HTTP/HTTPS monitoring section. When configuring an HTTP/HTTPS check, the user should be able to enable certificate monitoring via a simple checkbox (opt-in per check). Once enabled, the check inspects the endpoint's TLS certificate and raises alerts as the expiry date approaches, at one or more configurable day thresholds. Any number of thresholds should be supported, with sensible defaults of 15, 7, and 3 days before expiry.
Problem/Use Case
Expired TLS certificates are one of the most common and most avoidable causes of outages: browsers hard-fail, APIs stop trusting the endpoint, and clients see security warnings that instantly erode trust. Since HTTP/HTTPS endpoints are already being monitored in LogTide, the certificate is right there on the connection — checking its expiry adds a high-value early-warning signal at almost no extra cost. Multiple escalating reminders (rather than a single alert) ensure the warning isn't missed and give teams a clear runway to renew before the certificate actually lapses. This is especially important when managing many endpoints or client sites, where a single expired cert can take a production service offline.
Proposed Solution
Extend the existing HTTP/HTTPS check with an optional certificate-monitoring feature:
15, 7, 3. Max 3 values.Alternatives Considered
Implementation Details (Optional)
notAfterfield and computedays_remainingin UTC.[15, 7, 3]. Fire one alert per threshold as it is crossed, ideally de-duplicated so a given threshold only alerts once per certificate lifetime.Priority
Target Users
Additional Context
Certificate expiry monitoring is a baseline expectation for any HTTP/HTTPS monitoring tool, and integrating it directly into the existing check keeps configuration minimal for the user. The multi-threshold default (15/7/3 days) mirrors common industry practice and gives teams a clear, escalating renewal runway.
Contribution