Your certificate expiring shouldn't be the customer's job to report.
Most teams don't watch certificate expiry directly — they trust whatever renews it automatically, and find out it stopped working when someone hits a browser warning instead of the site.
It happens to teams with real infrastructure staff, too.
GitLab's own public infrastructure tracker has logged the certificate for
snowplow.trx.gitlab.net
expiring on the same calendar date two years running —
July 2023 and July 2024 — each time knocking out event collection for hours until someone
noticed and renewed it.
crates.io — the Rust package registry — went down for 86 minutes in 2016 after its certificate expired. The team had already received a renewal notice three weeks earlier and still missed it.
Same failure. Different first alert.
-
Certificate issued, renewal set to run automatically.
-
Renewal fails quietly — an expired API key, a DNS change, a rate limit.
-
Certificate expires. Nobody's watching for it.
-
A customer's browser warning is the first anyone hears about it.
-
Certificate issued, renewal set to run automatically.
-
Renewal fails quietly, same as before.
-
HeimPulse flags it — your configured number of days before expiry.
-
Renewed before anyone outside your team ever notices.
How it works
-
1
Add the host. Just a hostname — not a full URL, and not tied to any particular service. The same certificate can back several services, or none.
-
2
Set your warning window. 14 days by default, adjustable anywhere from 1 to 365 depending on how much lead time you want.
-
3
It's checked on a recurring schedule. A real TLS handshake against the host, reading the certificate a real visitor would actually get — not a cached assumption that renewal worked.
-
4
Cross the threshold, get notified. Through whichever channels you've already configured — webhook, Slack, or email.
example.com
warn under 14 days
api.example.com
warn under 14 days
Frequently asked questions
Do I need to set anything up separately from my existing checks?
Yes — a monitored certificate is its own resource, not something inferred automatically from your endpoint checks. You add the host once (just the hostname, like example.com — not tied to a specific service, since the same certificate can back several services or none) and it's checked from then on, independent of any HTTP monitoring you've already configured.
How many days before expiry does it warn me?
Whatever you set — there's a configurable threshold (14 days by default, adjustable from 1 to 365) per certificate. Cross it and you're warned; the dashboard also shows the real days-remaining count at a glance, not just a pass/fail state.
How does it actually check the certificate?
HeimPulse performs a real TLS handshake against the host, using the same certificate verification path a browser relies on — so what you see is the certificate a real visitor would actually get presented with, not a cached guess.
Where do the warnings show up?
Through whichever notification channels you've configured — webhook, Slack, or email. Certificate warnings are their own event type, separate from service incidents.
Which plans include SSL certificate expiry monitoring?
Pro and Business. It's not available on the Free plan. See the pricing page for the full breakdown.
Full SSL monitoring feature → · Where an incident shows up when one does happen → · All solutions →
Stop trusting renewal to fail quietly.
Free plan, no credit card, set up in a few minutes.