Real-time SSL certificate alerts

An SSL certificate that expires silently takes your site, API, or internal tool offline the moment a browser tries to connect. The browser shows a full-screen security error — not a slow page, not a partial failure, a complete block. Getting an alert 30 days before expiry rather than on expiry day is the difference between a planned renewal during business hours and an emergency page to on-call at midnight. SSL certificate alerts exist to make that window visible before it closes.

The four alert thresholds correspond to four different required actions. At 30 days: verify that auto-renewal is configured, the ACME challenge will succeed, and the payment method for a commercial CA is valid. At 14 days: if auto-renewal has not run, initiate a manual renewal now — there is still time for a normal change management process. At 7 days: a renewal that has not happened is now urgent; escalate immediately and start a manual renewal today. At 1 day: emergency — someone needs to act within hours or production will go down. Without staged thresholds, a single alert arrives when the cert is already expired, at which point every option is urgent.

Idempotent alert delivery is a design requirement, not an optimization. A monitoring system that fires one alert per check cycle — checking every 5 minutes and sending 288 "your cert expires in 3 days" emails per day — trains on-call engineers to ignore the monitoring system. CertFleet fires exactly one alert per threshold crossing per certificate. When the 14-day threshold is crossed, one notification is sent. When the 7-day threshold is crossed, one notification is sent. Recovery does not re-trigger expired thresholds. Each crossing is independent and fires once.

Alert channels are configured per certificate. Email is the baseline and always available on the free tier. A dedicated Slack channel routes cert alerts to the infrastructure team without spamming general channels. HMAC-signed webhooks (Starter plan and above) deliver a structured JSON payload to any receiver: PagerDuty, Opsgenie, a custom AWS Lambda, or a Slack incoming webhook with custom formatting. The webhook payload includes the certificate serial, expiry date, days remaining, current issuer, domain name, and alert threshold that triggered — everything a downstream incident management system needs to create and route a ticket. SMS is available on paid plans for the highest-urgency scenarios.

The webhook payload is deterministic and documented. A 30-day alert and a 1-day alert for the same certificate have the same payload structure — only the threshold and daysRemaining fields differ. This makes it straightforward to build conditional logic in your incident tool: route 30-day alerts to a low-priority ticket queue, 7-day and 1-day alerts to a P1 incident. All webhook deliveries are signed with an HMAC-SHA256 signature over the payload body using a per-account secret, so your receiver can verify the request genuinely came from CertFleet.

Certificate Transparency new-cert alerts fire on a different trigger. When a new certificate appears in CT logs for one of your monitored domains — whether from your own renewal or from an unexpected issuance — an alert fires immediately, before the certificate even reaches port 443. This is a security signal: an unauthorized certificate issued for your domain (via a compromised CA or a social-engineering attack on your DNS provider) will appear in CT within 24 hours. Getting this alert means you can request revocation before the certificate can be used against your users.