Monitoring SSL/TLS Certificate Expiry with Uptime Kuma

Disclosure: this article contains an affiliate link. DotExe may earn a commission if you purchase through it, at no extra cost to you. Any discount is subject to Hostinger's current offers (20% OFF) and eligibility terms.

Unexpected SSL/TLS certificate expiration is a common, yet entirely preventable, cause of service outages. When a certificate expires, browsers and API clients immediately reject connections, leading to broken user experiences and failed service-to-service communication. For developers managing multiple self-hosted services, manually tracking expiration dates is error-prone and inefficient. Uptime Kuma provides a robust, visual, and automated solution to monitor these certificates and alert you well before they expire.

Why Automated SSL Monitoring Matters

Modern web infrastructure relies heavily on TLS for security. While automated certificate management tools like Certbot or ACME protocols have simplified the renewal process, they are not infallible. Cron jobs can fail, DNS challenges can time out, or configuration changes can break auto-renewal scripts. Without a secondary monitoring layer, you might not realize a certificate has expired until a user reports a security warning or your application logs start flooding with TLS handshake errors.

By implementing dedicated monitoring, you shift from reactive troubleshooting to proactive maintenance. Uptime Kuma allows you to define specific thresholds for expiration alerts, giving you enough lead time to investigate why an automated renewal failed or to manually intervene if necessary. This shift is essential for maintaining the trust of your users and the integrity of your network traffic.

Understanding the Monitoring Architecture

Uptime Kuma functions as an independent observer. When you configure a certificate monitor, the application performs a TLS handshake with your target domain. It extracts the certificate chain, inspects the Not After field, and calculates the remaining validity period.

This process is decoupled from your actual application logic. Even if your backend service is running correctly, the certificate monitor ensures the transport layer remains secure and valid. This separation of concerns is critical for maintaining high availability in your infrastructure. Because Uptime Kuma operates outside the target service's execution environment, it provides an objective view of how an external client, such as a browser or a mobile app, perceives your site's security configuration.

Setting Up Uptime Kuma for Certificate Tracking

If you have not already deployed the tool, you can follow our guide on how to set up Uptime Kuma with Docker Compose. Once your instance is running, follow these steps to configure your first certificate monitor.

1. Create a New Monitor

Log in to your Uptime Kuma dashboard and click the Add New Monitor button. In the monitor type dropdown, select Certificate Expiry. This specific monitor type is optimized for checking the validity of SSL/TLS certificates rather than just checking if a port is open. Unlike a standard HTTP/HTTPS monitor, which checks for a 200 OK status, the certificate monitor focuses exclusively on the cryptographic metadata of the handshake.

2. Define the Target

Provide the hostname or domain name you wish to monitor. Ensure that the port is set correctly—usually 443 for standard HTTPS traffic. If you are monitoring a service behind a reverse proxy, ensure the proxy is passing the correct SNI (Server Name Indication) information so that the handshake succeeds. If you are using a non-standard port or a custom internal service, ensure that the firewall allows traffic from your Uptime Kuma container to the target port.

3. Configure Alert Thresholds

This is the most important step for preventing outages. You can define how many days before expiration you want to receive an alert. A common best practice is to set a primary alert at 30 days and a critical alert at 7 days. This gives you a buffer to resolve potential issues without immediate pressure. For production environments, consider setting an additional warning at 14 days to ensure that you have enough time to debug any failures in your automated renewal pipeline, such as a blocked port 80 or a failed DNS challenge.

4. Configure Notifications

Monitoring is only useful if you see the alerts. Ensure you have configured your notification channels—such as Discord, Slack, or email—as detailed in our guide on configuring Uptime Kuma notifications. Link these channels to your new certificate monitor to ensure you are notified immediately when a threshold is breached. It is often helpful to route these alerts to a dedicated channel that your team monitors daily, rather than a personal inbox where they might be overlooked.

Advanced Diagnostics and Troubleshooting

If a monitor reports a failure, it does not always mean the certificate is expired. It could indicate a network issue or a misconfigured proxy.

Common Failure Modes

• Handshake Failures: If the monitor cannot complete a TLS handshake, check if your firewall is blocking the connection or if the target service is down. You can use tools like openssl s_client -connect domain.com:443 from the Uptime Kuma container to debug the connection manually. This will reveal if the server is returning an unexpected certificate or if the connection is being dropped before the handshake completes.
• Incorrect Chain: Sometimes, the server sends an incomplete certificate chain. While browsers might be forgiving, Uptime Kuma may report an error. Ensure your web server (Nginx, Caddy, etc.) is configured to serve the full chain, including intermediate certificates. You can verify this by checking the server configuration against common SSL testing tools.
• Time Synchronization: Ensure the system clock on your Uptime Kuma host is accurate. If the server time is significantly skewed, the certificate validation logic will produce incorrect results. Use NTP (Network Time Protocol) to synchronize your host clock to ensure that the Not After calculations remain accurate.

Verifying the Setup

You can verify your configuration by temporarily setting a very high expiration threshold (e.g., 365 days). If the monitor turns red and triggers an alert, you know the notification pipeline is working correctly. Remember to revert this setting after testing to avoid unnecessary noise. This verification is a critical part of your disaster recovery planning, as it confirms that your alerting path is functional before you actually hit a critical expiration event.

Integrating with Broader Infrastructure

For complex environments, you might want to monitor services that are not publicly accessible. In such cases, you can use a VPN tunnel to bridge your monitoring instance to your private network. See our guide on how to monitor private services with Uptime Kuma via WireGuard to ensure your internal services are just as secure as your public-facing ones.

Furthermore, consider the impact of certificate expiry on your internal microservices architecture. If you have services that communicate via mTLS (mutual TLS), each service needs to have its own certificate monitored. You can create a group of monitors in Uptime Kuma to track these internal certificates collectively, allowing you to see the health of your entire service mesh at a glance.

If you are looking for a reliable place to host your web projects, you might consider Hostinger Web Hosting. They provide robust infrastructure that supports standard SSL/TLS configurations, making it easier to maintain secure services.

Disclosure: this article contains an affiliate link. DotExe may earn a commission if you purchase through it, at no extra cost to you. Any discount is subject to Hostinger's current offers (20% OFF) and eligibility terms.

Scaling Your Monitoring Strategy

As your infrastructure grows, the number of certificates you need to manage will increase. It is common to have certificates for public websites, internal APIs, development environments, and even VPN endpoints. Managing these manually is impossible. Uptime Kuma's ability to import and export configurations allows you to maintain a consistent monitoring baseline across different environments. You can use the API to programmatically add monitors as you provision new services, ensuring that no new endpoint is deployed without an associated security check.

Consider the trade-offs of your monitoring frequency. While you want to be alerted quickly, checking every minute might be unnecessary for certificate expiry. A check frequency of once or twice a day is usually sufficient for certificates that last for months. This reduces the load on your monitoring infrastructure and prevents unnecessary logs. However, if you are using short-lived certificates (such as those issued by some internal PKI systems), you may need to increase the frequency to ensure you catch an expiration before it causes an outage.

Finally, remember that Uptime Kuma is a tool for observability, not for automated remediation. While it can tell you that a certificate is about to expire, it cannot fix the underlying issue. Your focus should be on building a robust automated renewal system, such as using Certbot with a web server hook or a sidecar container that handles certificate rotation. Uptime Kuma serves as the final safety net, alerting you when your primary automation fails.

Conclusion

Automating SSL certificate monitoring is a foundational step in maintaining a resilient and secure infrastructure. By leveraging Uptime Kuma, you eliminate the risk of human error and ensure that your services remain accessible and trusted by your users. Start by monitoring your most critical domains today, and gradually expand your coverage to all internal and external endpoints. By treating your security certificates with the same level of care as your server uptime, you can prevent one of the most common and easily avoided causes of downtime in modern web applications.