SSL Monitoring Configuration Guide

Expired SSL certificates are one of the most common — and most preventable — causes of customer-facing outages. Pingara automatically tracks SSL/TLS certificates on every HTTPS monitor and warns you well before they expire.

How SSL Monitoring Works

Whenever Pingara performs an HTTPS check, it inspects the certificate presented by your server.

Each check captures:

• Certificate validity dates — Not before / Not after
• Days until expiry — Calculated from current time
• Certificate chain — Validated against trusted CAs
• Hostname match — CN/SAN matches the monitored URL

This data is stored with every check result, so you can review certificate health over time.

What Gets Detected

Pingara raises alerts for:

• Upcoming expiry — Certificate approaching its end date
• Expired certificate — Already past the not-after date
• Invalid chain — Missing intermediate certificate
• Hostname mismatch — Certificate doesn't cover the monitored host
• Self-signed certificate — Not signed by a trusted CA
• Untrusted issuer — CA not recognized by standard trust stores

Tip: A "valid" certificate that doesn't match your hostname will still fail HTTPS checks. Always validate the certificate covers every domain you serve.

Default Warning Thresholds

Out of the box, Pingara fires SSL warnings at:

• 30 days before expiry
• 14 days before expiry
• 7 days before expiry

These cover most renewal workflows, including manual renewals and Let's Encrypt automated renewals.

When Alerts Fire

Pingara sends one alert per threshold crossed:

Day 30 → First warning sent
Day 14 → Second warning sent
Day 7  → Final warning sent
Day 0  → Certificate expired (incident created)

You won't receive duplicate alerts at the same threshold — preventing notification fatigue.

Customizing Warning Thresholds

For high-risk certificates, add more aggressive reminders.

Configuration

In monitor settings, set SSL Expiry Warning Days:

30, 14, 7, 3, 1

You'll now also be alerted at 3 days and 1 day before expiry.

Recommended Thresholds By Use Case

Revenue-critical APIs:

60, 30, 14, 7, 3, 1

Maximum lead time for renewal coordination.

Standard production services:

30, 14, 7

Pingara default — fits most workflows.

Automated renewals (Let's Encrypt, ACM):

14, 7, 3, 1

Short windows because renewals run automatically; alerts indicate renewal failure.

Internal-only services:

30, 7

Lower urgency, fewer notifications.

Configuring SSL Monitoring

Enabling SSL Tracking

SSL monitoring is automatic for any HTTPS URL. There is no separate toggle — if your monitor URL begins with https://, Pingara tracks the certificate.

Where to Configure

1. Open the monitor in Monitors → Edit
2. Scroll to SSL/TLS Settings
3. Set SSL Expiry Warning Days (comma-separated list)
4. Click Save

Per-Monitor Configuration

Each monitor has its own thresholds, so you can tune urgency per service:

• Checkout API → 60, 30, 14, 7, 3, 1
• Marketing site → 30, 14, 7
• Internal admin → 14, 7

Reading SSL Status

On the Monitor Detail Page

The monitor detail page and incident timeline surface SSL failures as check errors when certificates are expired or invalid. Detailed certificate metadata fields (issuer/expiry timestamps) are not yet displayed in the UI.

Status Indicators

When Expiry Becomes an Incident

A certificate that has already expired causes HTTPS checks to fail. Pingara then:

1. Marks the check as failed (TLS handshake error)
2. Increments the consecutive failure counter
3. Creates an incident after 2 consecutive failures (and regional quorum if multi-region)
4. Fires down alerts on every configured channel

Expiry warnings are separate from incident alerts — warnings give you time to renew, incidents fire when the certificate is already invalid.

Best Practices

Automate Renewals

Manual renewals are the #1 cause of certificate-related outages. Use:

• Let's Encrypt + certbot — Free, auto-renewing certs
• AWS Certificate Manager — Auto-renews for AWS-managed certs
• Cloudflare Universal SSL — Managed by Cloudflare edge
• Caddy — Auto-issues and renews via Let's Encrypt

Use Wildcard Certificates Carefully

A wildcard cert (*.example.com) simplifies management but creates a single point of failure. If it expires, every subdomain breaks at once.

Recommendation: Monitor every subdomain that uses the wildcard separately, so per-subdomain status reflects the actual customer experience.

Cover Every Hostname You Serve

A common pitfall: a certificate covers example.com but not www.example.com (or vice versa). Create a Pingara monitor for each hostname you serve over HTTPS — including:

• Apex domain (example.com)
• WWW subdomain (www.example.com)
• API subdomains (api.example.com)
• Status page (status.example.com)

Renew Well Before Expiry

Schedule renewals at 14+ days before expiry to leave room for:

• Failed renewal jobs (retry capacity)
• DNS validation propagation delays
• Manual approval steps for EV/OV certificates

Subscribe the Right People

Route SSL alerts to the team that owns certificate renewal — usually DevOps, SRE, or Platform. See Setting Up Alerts for channel and event preferences.

Troubleshooting

"Certificate Expired" but renewal succeeded

Cause: The web server is still serving the old certificate from disk or memory.

Fix:

• Reload the web server (nginx -s reload, systemctl reload caddy, etc.)
• Restart the load balancer or proxy
• Clear cached certificates on the CDN

"SSL certificate invalid" on a fresh certificate

Causes:

• Missing intermediate (chain) certificate
• Wrong file order in PEM bundle
• Hostname not in SAN list

Fix:

• Validate with openssl s_client -connect example.com:443 -servername example.com
• Use SSL Labs Test for a detailed report
• Ensure the full chain (leaf + intermediates) is served

"Hostname mismatch"

Cause: Certificate CN/SAN does not include the URL being monitored.

Fix:

• Reissue the certificate with all required SANs
• Update DNS to point to a host whose cert covers it
• Monitor the hostname that's actually on the certificate

Warnings keep firing after renewal

Cause: Pingara reads the certificate live on every check — if warnings keep firing, the server is still serving the old cert.

Fix: Verify externally with:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

The notAfter date should reflect the new certificate.

Let's Encrypt rate limits

Let's Encrypt enforces issuance limits per registered domain. If automated renewal fails repeatedly:

• Check certbot logs for rate-limit errors
• Use the staging environment for testing
• Wait for the rate-limit window to reset (usually 1 week)

SSL Monitoring and Status Pages

Public status pages can display certificate health for transparency. SSL incidents that result in a "down" status appear on the public status page like any other incident.

For Pro plans, you can also let subscribers receive incident notifications — see Status Pages.

Next Steps

• HTTP/HTTPS Monitoring — Configure the underlying HTTPS check
• Setting Up Alerts — Route SSL warnings to the right team
• Monitor Intervals and Regions — Optimize check frequency