SSL Monitoring
An expired SSL certificate will create a total outage. It's easy to configure HeyOnCall to notify your team about any soon‑to‑expire SSL certificates, so you have plenty of time to take action before there's a customer‑visible outage.
SSL Certificate Monitoring:
HeyOnCall’s monitoring continuously checks your website (homepage, health check endpoints, CDNs, etc.) by sending HTTPS requests. When SSL certificates are invalid or expired, or your site is otherwise down, we alert your team via loud critical alerts to our iOS and Android apps, post the incident to your Slack channel, and keep alerting and escalating until someone on your team acknowledges.
However, for the special case of monitoring SSL certificate expiration, you'd like to be notified before the certificate expires. We let you configure gentler, non-critical alerts which can be deferred until your regular business hours, for example, if your certificate expires in 14 days. If that goes unfixed, you can set up critical alerts when your certificate expires in 48 hours. Customize these thresholds and alerting rules to fit your team.
TLDR:
Built for small engineering teams and solo founders, HeyOnCall pairs SSL certificate monitoring with on‑call alerting in one product for superior reliability and simplicity. Get impossible-to-ignore critical alerts that bypass Do Not Disturb, plus Slack, email, webhooks, and more. Defer alerts that can wait (like those about not-yet-expired certificates) until your regular business hours. HeyOnCall is designed from the ground up to reduce false positive alerts (getting alerted when your site is actually up) and false negatives (missing an outage due to broken monitoring or alerting).
SSL Certificate Monitoring: HeyOnCall vs. Alternatives
| Differentiator |
HeyOnCall
|
Alternatives |
|---|---|---|
| SSL checks | Asserts valid SSL certificate and certificate chain. | Varies, but similar. |
| Expiration monitoring | Customizable days‑til‑expiration threshold. Custom rules at different days‑til‑expiration thresholds: non-critical vs. critical, deferral until business hours, etc. | ¯\_(ツ)_/¯ |
| Business hours schedules | Defer important-but-not-urgent alerts (like a certificate expiring in two weeks) until your preferred weekdays and hours. | No differentiation between urgent and non-urgent alerts. Burns out your on-call team waking them up for things that can wait until the morning. |
| Alerting | iOS/Android “Critical Alerts” bypass Do Not Disturb and volume/mute settings. Repeat until acknowledged. Will wake you up! | No mobile app. No critical alerts. Emails or Slack alerts are easy to miss for hours. |
| On‑call | Integrated on-call rotation schedules and escalations. | Separate products for monitoring and on-call: requires integration glue between them, so there are more moving parts to fail during an outage. |
| Silencing | Quick silence with selectable timeout at the trigger, service, or organization-wide level. Ensures you don’t keep getting alerts while you’re fixing the issue, and ensures you don’t inadvertently stay silenced forever. | Mute one monitor at a time. Forget to unmute after the incident is over, so you miss the next incident. |
| False positives (noisy alerts) |
Customer-level: False positives are reduced to your preferences via customizable consecutive-failure thresholds / timeouts. Platform-level: False positives are reduced through continuous control group self-checks, extensively tested codebase, and code paths designed to differentiate our network incidents from yours. |
¯\_(ツ)_/¯ |
| False negatives (missed alerts / blind spots) |
Customer-level: Missed alerts are reduced via: alerts repeat until acknowledged; configurable multiple delivery channels per user; configurable multi-level escalations. Blind spots are reduced via configurable assertion rules on HTTP response headers, etc. Platform-level: False negatives are reduced via extensive CI test suite, continuous production self‑checks, and external monitoring. |
Customer-specific glue (webhook integration) between separate monitoring product and on-call product fails silently (webhooks/auth headers/network issues), resulting in missed alerts right when you need them. |
| Pricing | Simple, flat $/month pricing. Free tier forever. | Annoying $/user/month or $/monitor/month. |
SSL Certificate Monitoring FAQs
Why do SSL certificates need monitoring?
Monitoring your SSL certificates is essential to anyone with an
https://
website or API. Here's what might break:
- For automatically renewed SSL certificates (e.g. Let's Encrypt): protect against a cron job that doesn't run, a Python dependency change that breaks certbot, a DNS‑01 provider authentication issue with your registrar / DNS provider / Route53 IAM, an HTTP‑01 integration issue with serving the ACME challenge, a CA outage, a root certificate issue on your ACME client, an IPv6 change gone wrong, a Kubernetes issue breaking cert‑manager, etc.
- For manually rotated SSL certificates: protect against the person who renewed the certs last year going on vacation, forgetting to do it in time, requesting the renewal via CSR but not deploying it to production, deploying the wrong certificate file, etc.
- For platform‑managed SSL certificates: protect against being lost in some edge case in their SSL certificate renewal code, the platform's upstream CA rate limits being hit, etc.
What happens when SSL certificates expire?
In modern web browsers, an expired SSL certificate results in your users seeing a big, scary warning when they try to visit your website. API users are also denied, throwing exceptions such as
ssl.SSLCertVerificationError
or
OpenSSL::SSL::SSLError
which their code may not be prepared to handle. In both cases, this is a severe user‑facing outage that makes your website or API inaccessible to your users. The outage continues until the SSL certificate is renewed by your team.
Who needs SSL certificate monitoring?
Anyone responsible for an HTTPS website or API should probably take a few minutes and set up their own monitors to let them know if and when their certificate renewals are broken for whatever reason.
How does HeyOnCall monitor SSL certificates?
HeyOnCall's outbound probes continuously monitor a URL, such as your health check endpoint, by sending HTTPS requests. Immediate failures are classified as
ssl_error,
while upcoming expiration within your configured threshold (e.g. 14 days) is classified as
ssl_certificate_expires_soon.
When do I get alerted?
You choose how soon your SSL certificate needs to expire before we alert.
You probably don’t want to get woken up by a loud alert at 3am if your certificate is expiring in two weeks from now.
On the other hand, if your certificate is expiring in 24 hours and you missed the earlier non-critical alert, you probably want to get woken up and start debugging.
There are real tradeoffs in setting your timeout threshold, but for SSL monitoring, we typically recommend something like 14 days for non-critical alerts and 2 days for critical alerts.
Who gets alerted?
Alerts route to the on‑call person in your on-call rotation schedule.
This works for solo founders too: until you add teammates, the default on-call schedule is just you, 24/7!
How do I get alerted?
Alerts are sent via the free HeyOnCall mobile apps for iOS and Android.
We have special permissions to deliver “Critical Alerts” on both iOS and Android. Critical alerts bypass the phone’s Do Not Disturb and silent/vibrate modes. They are LOUD and impossible to ignore.
The alerts will keep getting sent repeatedly (at a configurable interval) until you acknowledge the incident.
That sounds incredibly annoying! How do I turn it off?
Acknowledging the incident stops the alerts.
You can also configure non-critical alerts, which will be delivered as normal push notifications. These respect your phone’s normal Do Not Disturb and silent/vibrate modes.
We also have a vibrate-only mode, which will still buzz in your pocket, but won’t make any sound.
During an incident, you can also silence all alerts at multiple levels up to organization-wide, so you don’t keep getting paged while you’re in the middle of trying to debug things.
What if I don’t notice the alert?
We have escalation rules built in. You can configure HeyOnCall to, for example, page the next person after 15 minutes, then page the team’s manager after 30 minutes, then page the CTO after 60 minutes. Any one of those people acknowledging the incident will stop the escalation.
Can I get alerts in Slack?
Yes. Connect Slack and our bot will post messages into your desired Slack channel for team visibility and collaboration. You can use this Slack channel for team awareness, while you rely on the iOS/Android critical mobile alerts for wake-you‑up-at-3am paging.
What makes HeyOnCall better than alternatives?
Alternative solutions often require you to stitch together separate monitoring and on-call alerting tools using brittle webhooks between them. For example: would you really trust your self-hosted monitoring server to be able to send a POST request to your third-party alerting service exactly when you’re in the middle of a flaky network outage? :facepalm: Not exactly a recipe for reliability.
HeyOnCall integrates website monitoring, SSL monitoring, cron job monitoring, on‑call schedules, and alert delivery in one product, which removes fragile links and makes the overall system more reliable.
Critical alerts. On-call schedules. Escalations. Monitoring for websites, APIs, cron jobs, and SSL certificates. All built-in and battle-tested. Designed for developers, by developers. Simple, flat pricing. Free tier forever.
How fast can I get started?
Sign up (free tier forever), add a URL, and start receiving checks in about a minute.
Live sandbox resets hourly.
No sign-up required.
No credit card required.
Free tier forever.