Route Certificate Expiry and Availability Alerts to Different Teams

Give the two conditions separate identities

An unavailable HTTPS endpoint and a certificate expiring next week can share a hostname while requiring different work. Write two service contracts: the availability owner restores access; the certificate owner renews and deploys the certificate. Define a fallback owner when the assignment is missing.

Use stable event keys such as shop:https:availability and shop:https:certificate-expiry. These are example keys for your event model, not built-in fields promised by a monitoring product. Keep the hostname, environment, observation time, owner, and threshold with each event.

Do not put an enormous retry count on an HTTP monitor simply to suppress downtime. That can conceal a long period in which the monitor cannot inspect the certificate at all. A displayed expiry date may then describe the last successful connection, not the certificate currently served.

Separate measurement from notification

A probe capable of inspecting TLS can feed a certificate rule while an HTTP result feeds an availability rule. Blackbox exporter configuration (opens in a new tab) is one implementation reference for protocol checks; use the metrics actually emitted by your installed release and inspect them before writing alert expressions.

For expiry, decide which certificate matters: the public load balancer, origin endpoint, internal service, or all of them. Preserve the intended hostname and SNI when checking an origin address. A certificate on an IP-based default virtual host may belong to another service.

The lead time is an operational choice based on renewal and deployment speed. It is not a reason to wake the network team for every early renewal reminder.

Make routing predictable

Route by explicit labels or event types. Alertmanager (opens in a new tab) supports routing and grouping; an equivalent supported workflow in another receiver is also suitable. Avoid routing on translated human-readable messages such as “SSL warning,” which can change between versions.

Give maintenance a precise scope. Planned application downtime may suppress availability paging while leaving certificate reminders active. A maintenance entry for the whole hostname can otherwise suppress both. Include an expiry time and owner for the maintenance exception.

If the installed Uptime Kuma release cannot separate the two notification types as required, use a dedicated external certificate probe and route its results separately. Confirm the available controls in that release instead of assuming a status-page expiry display provides notification routing.

Validate the four paths

Use test endpoints or a controlled rule threshold to exercise renewal warning, invalid TLS, failed HTTP response, and missing certificate observation. Capture which team received each message. Then renew the test certificate and verify the receiver closes the matching expiry event without closing an unrelated availability incident. Keep this routing matrix with the certificate inventory so a future team or proxy change does not silently reverse the responsibilities.