SSL Monitoring

Get alerted before your SSL certificate expires, and as soon as it starts failing for your visitors. Hyperping checks the certificate of every HTTPS monitor once a day, with no extra setup. For an overview of the feature, see SSL monitoring.

What is checked

Each check opens one TLS connection, the way a browser would, and verifies what the server actually serves. A certificate your provider renewed but your server doesn't serve yet still counts as expiring.

Expiry alerts

In the monitor's Notifications tab, SSL Expiry Alerts sets how many days before expiry the first alert goes out: 1, 3, 7, 15, 30, 60 or 90 days, or never. With Send reminders on, a reminder follows at each step below it: with 30 days, alerts go out at 30, 15, 7, 3 and 1 days before expiry.

• Nothing is missed. If a check couldn't run on the day a reminder was due, the reminder goes out on the next check, once.
• No reminder after a renewal. The certificate is read again right before a reminder is sent: if it was renewed in the meantime, nothing goes out. If you had already been warned, a renewed notice follows instead.
• Who gets them. Everyone on the project by email, plus the monitor's SSL notification channels (Slack, Microsoft Teams, Discord, Google Chat, Telegram, webhooks). PagerDuty and Opsgenie are only paged in the last 24 hours, and the renewal resolves the page.

Certificate error alerts

When a check finds a new problem, the monitor's SSL notification channels get an alert listing every issue on the certificate. When all problems are gone, they get a resolved notification. An issue that persists is not repeated every day, and an issue that was already there when the monitor was created is shown on the monitor but doesn't trigger an alert.

Pick the channels in the monitor's Notifications tab, under SSL notification channels.

Certificate change notifications

Turn on Certificate changes to be told whenever the server starts serving a different certificate: a renewal, a new issuer, a new key. The notification shows the new and the previous certificate. It goes to the SSL channels, or to the team by email if the monitor has none. A load balancer or CDN that serves several certificates at once doesn't trigger it: a certificate seen in one of the last three checks doesn't count as new.

Monitor list and certificate details

Each HTTPS monitor in the list shows the days left on its certificate, and a badge such as CN Mismatch when a check fails. Click Filter, then Certificate errors, and pick one type of error (expired, self-signed, hostname mismatch, revoked, incomplete chain…) or Has any certificate error.

On a monitor's Overview, the SSL button (with the days left) opens the SSL certificate panel:

• Status and lifetime. Valid, expiring or failing, the days left, and a bar from the issue date to the expiry date with the alert window marked. A warning appears when an automated certificate is past the point where it should have renewed.
• Expiry alert. When the first alert and the reminders will fire. Change opens the Notifications tab.
• Checks. Each check from the table above, with an explanation when it fails.
• Hostnames covered, Details (common name, issuer, validity, serial number, first seen) and the Chain of trust the server sends.
• Domain registration, when known: see domain expiry monitoring.

Refresh a certificate manually

Certificates are checked daily around 04:00 UTC. To read a renewed certificate right away:

1. Open your monitor

   Go to the monitor whose certificate you renewed.

2. Open the certificate panel

   On the Overview tab, click the SSL button.

3. Click Recheck

   The panel refreshes with the certificate the server serves now. Alerts follow the same rules as the daily check. On a monitor with no certificate read yet, the button is called Fetch certificate.

API and Terraform

The same settings are available on monitors in the API: ssl_alert_days (-1 for never), ssl_reminders and ssl_notify_on_change. ssl_expiration is read-only: the whole days left before the certificate expires, rounded down, so a certificate expiring tomorrow afternoon shows 1. The Terraform provider's hyperping_monitor resource takes the same three settings.

curl -X PUT https://api.hyperping.io/v1/monitors/mon_3GhAQMYGEQuyUH \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "ssl_alert_days": 30,
    "ssl_reminders": true,
    "ssl_notify_on_change": true
  }'

Webhook payloads

Webhooks added as SSL channels receive certificate error alerts in the same shape as before:

{
  "event": "down",
  "isDown": true,
  "status": "SSL_ERRORS_DETECTED",
  "sslEvent": true,
  "domain": "https://example.com",
  "alias": "Website",
  "timestamp": "Oct 01 2026, 04:02:11 UTC"
}

Informational notices have their own event and always carry "isDown": false, so a consumer that acts on event === "down" ignores them: ssl_expiring, ssl_renewed, ssl_changed, domain_expiring and domain_renewed.

{
  "event": "ssl_expiring",
  "isDown": false,
  "status": "SSL_EXPIRING_SOON",
  "sslEvent": true,
  "monitorUuid": "mon_3GhAQMYGEQuyUH",
  "domain": "https://example.com",
  "alias": "Website",
  "daysRemaining": 7,
  "expirationDate": "2026-10-08T23:59:59.000Z",
  "issuer": "R11",
  "fingerprint": null,
  "previous": null,
  "timestamp": "Oct 01 2026, 10:00:03 UTC"
}

Troubleshooting

Next steps