SSL certificate monitoring in Tracker.ru is automatic SSL/TLS chain validation on every uptime check, plus expiration alerts at 30, 14 and 7 days before expiry. Alerts go to Telegram, the MAX messenger, email and webhook — the same channels as regular site-down alerts. No separate integration, no CSV exports, no manual calendar reminders: add a URL — SSL monitoring is on by default.
Why monitor an SSL certificate
An expired SSL is the most embarrassing «half-down» state a site can be in. Technically the server is up and pages return 200 OK over HTTP, but the browser blocks the site with a fullscreen warning «Insecure connection, your data may be stolen». Conversion rate collapses, and the team finds out about the issue from support tickets, not from monitoring.
There are plenty of ways to forget about a certificate's expiry. Let's Encrypt auto-renew runs from cron, which broke after a server migration and nobody noticed — there are no renewals, and nobody set a calendar reminder 30 days out. Sometimes a paid CA certificate is registered under the email of an ex-employee, and renewal notices go nowhere. Or the chain is misconfigured (intermediate certificate not served), and some users see an SSL error while others don't, depending on browser.
A separate SSL monitor handles all these cases: the system itself checks the certificate on every request to the site, compares the expiry date with the current time, and fires an alert at 30, 14 and 7 days before expiry — regardless of who set up auto-renew or when. If auto-renew works correctly, the 30-day alert arrives, the certificate renews the next day, and the cycle resets. If auto-renew is broken, the alert tells you 30 days in advance — you have time to investigate and renew manually, without firefighting.
What Tracker.ru actually checks and when alerts fire
On every uptime check (intervals from 30 seconds to 1 hour, depending on plan), Tracker.ru connects to the site over HTTPS and validates the SSL/TLS chain: certificate expiry date (notAfter), chain validity (intermediate signed by trusted root), name match (the certificate was issued for the right domain or its wildcard), and basic trust signals (CA known, certificate not revoked).
If the certificate is approaching expiry, Tracker.ru fires three alerts at different horizons so the team has time to react without panic.
At 30 days. A quiet preventive alert: if auto-renew is configured, the certificate renews the next day and no further alerts arrive. If auto-renew failed, you have a month to calmly investigate.
At 14 days. If two weeks before expiry the certificate hasn't renewed, it's time to take the process under manual control. The alert fires a second time, in a more visible tone.
At 7 days. The final alert. If by this point the certificate isn't renewed, the situation is critical — issue a new certificate and install it manually right now. The 7-day alert duplicates across all configured channels (Telegram + MAX + Email + Webhook), even if the previous two were ignored.
Between thresholds an anti-flap dedup applies: a repeat alert for the same certificate fires no more than once per 24 hours. One certificate — one chain of alerts (30 → 14 → 7). If the certificate is renewed, the cycle automatically resets and the next chain runs from the new notAfter.
Alerts ride the same delivery channels as regular site-down notifications — no separate integration to set up: Telegram bot (@tracker_ru_bot), MAX messenger, email, and webhook (POST with JSON payload event: ssl.expiring, fields domain, days_left, expires_at, monitor_url, with HMAC-SHA256 signature). When the certificate is renewed, an additional ssl.renewed event fires — useful for auto-closing tickets.
Comparison with alternatives
There are a few replacements, each with trade-offs.
Manual calendar reminders. The most common substitute — set by hand in Google Calendar or Notion a month before expiry. Downsides: you maintain the domain list manually, doesn't account for auto-renew (fires even if the certificate already renewed), and gets lost across team turnover.
Custom script + cron. A homegrown openssl s_client + grep notAfter | mail. Works, but needs care: someone has to keep the script alive, configure SMTP, maintain the domain list in YAML, and re-implement non-email channels by hand. Six months later it becomes legacy nobody touches.
Specialized SSL monitors. rechecker.ru, ssldetect.com, certimon.com — narrow services for SSL only. Strengths: dedicated channels and extended checks (CT logs, CAA records). Downsides: yet another account, another bot, separate pricing — when you already have uptime monitoring elsewhere and the systems aren't connected.
Tracker.ru — uptime + SSL together. SSL checks ride along with the regular uptime check: one system, one account, one Telegram bot, one webhook endpoint. Site-down alerts and SSL-expiring alerts arrive in the same chat with the same shape. Dashboards and history live together. For non-Eurasian audiences, see the honest disclaimer: Tracker.ru focuses on Russia, EU and Kazakhstan check points; for global coverage from US/CN/AU, an international service like UptimeRobot is a better fit.
How to enable and what it costs
SSL monitoring is on by default for every URL monitored over HTTPS — nothing to configure separately. Add a URL in /my/urls and SSL checks start automatically.
- Free (0 ₽). Up to 5 monitors, 5-minute interval. SSL check works, 7-day alert. Fits pet projects and product evaluation.
- Basic (290 ₽/mo). Up to 20 monitors, intervals from 60 seconds. Full SSL alert chain (30, 14, 7). Enough for most commercial sites.
- Pro (790 ₽/mo). Up to 100 monitors, intervals from 30 seconds, extended notification channels and a public API. Full SSL analytics and renewal history.
Channel setup — in /my/notifications. More on plans — /pricing.
Enable SSL monitoring for free
Frequently asked questions
Do I need to enable SSL monitoring separately?
No. If a URL is monitored over HTTPS, the SSL check runs automatically as part of the regular uptime check. Nothing to configure — add the URL in /my/urls and the certificate is validated on every check. The 30/14/7-day expiration alert is enabled by default.
How many days before expiry do alerts fire?
Tracker.ru fires three alerts: at 30, 14 and 7 days before the expiry date. This lets the team react without panic: at 30 days — calmly verify auto-renew, at 14 — take the process under manual control, at 7 — emergency manual renewal if auto-renew still hasn't fired. Free plan only includes the 7-day alert; Basic and Pro include all three thresholds.
Will I get an alert every day after the first one?
No. Between alerts an anti-flap dedup applies: a repeat alert for the same certificate fires no more than once per 24 hours. One certificate — one chain of three alerts (30 → 14 → 7). If the certificate is renewed, the cycle automatically resets. No daily «29 days left... 28 days left...» spam — only three meaningful thresholds.
See also
- /features/heartbeat-monitoring — heartbeat monitoring for cron jobs
- /features/multi-region — checks from 3 regions (Moscow, Frankfurt, Almaty)
- /compare/uptimerobot — comparison with UptimeRobot
- /pricing — full plan and pricing comparison