Prometheus blackbox SSL expiry exporter

Prometheus ssl certificate expiry via Blackbox Exporter turns handshakes into time-series—probe_ssl_earliest_cert_expiry and friends—so Grafana can page before browsers do, provided your scrape targets mirror what customers resolve in DNS.

Platform teams adopt Blackbox because Prometheus already scrapes application metrics. SSL modules reuse that machinery: probe the public https endpoint, export expiry seconds, alert when (probe_ssl_earliest_cert_expiry - time()) drops below a threshold. The pattern is standard in blog posts and Helm examples.

The category is known for flexibility and for sharp edges—wrong module, internal resolver, or a target list that still says prod while marketing launched brand2 last quarter. Expiry metrics are only as honest as probe design.

This guide explains Blackbox strengths, where dedicated SSL monitoring still differs, fair comparison criteria, and pairing ssldays without dismantling your observability stack.

What Prometheus Blackbox does well

Blackbox is a probe multiplexer, not a certificate manager. For prometheus ssl certificate expiry, that separation is a feature.

Native Prometheus metrics. Exporters emit consistent labels; recording rules and SLO dashboards treat cert horizon like any other SLI.

HTTP/TCP/ICMP modules. One toolchain covers reachability and TLS on the same target file—helpful when correlating “probe success” with “days left.”

Alertmanager integration. Route certificate warnings through the same inhibition trees as service alerts so duplicate pages behave predictably.

Horizontal scale. Additional scrapers and exporter instances add capacity without negotiating SaaS contracts—only infrastructure cost.

Open metrics retention. Historical expiry trends support capacity planning and auditing after incidents.

Blackbox excels when SREs own YAML, review targets in code review, and understand SNI. It is weaker as a self-service panel for marketers who add domains weekly.

Recording rules that convert probe_ssl_earliest_cert_expiry into “days left” panels are well documented; what is less documented is who updates static targets when an agency client adds shop.clientname.com without a Jira ticket—prometheus ssl certificate expiry programs fail on process before they fail on PromQL.

Treat Blackbox expiry metrics as necessary for SLO culture, not sufficient for every registrar and SAN edge case your security team tracks outside Grafana dashboards.

Where SSL expiry monitoring differs

Metrics answer “what did Blackbox return last scrape?” Productized monitors answer “what should we tell humans who do not read PromQL?”

Inventory friction. Every hostname is a scrape target line. Managed monitors favor UI or API adds with ownership metadata.

RDAP registrar dates. Blackbox does not surface domain redemption risk. TLS may be valid while DNS validation will fail next quarter. Bundle check domain registration expiry thinking externally.

Chain and SAN narratives. Exporters expose timestamps; explaining partial SAN mismatches still needs openssl or richer alert text—see openssl s_client expiry diagnostics.

Non-engineer alerting. Email at staged thresholds without Grafana seats matters for compliance and brand teams.

External parity checks. Independent second opinion catches misconfigured modules faster than tuning PromQL alone.

Deduped human alerts. Recording rules can implement staging, but teams often page every evaluation until someone silences—managed products encode renewal-cycle deduplication by default.

Keep Blackbox for metric truth inside your observability culture. Add external watches when hostname governance spans departments your Blackbox configs do not reach today.

Side-by-side criteria

Score Blackbox-based prometheus ssl certificate expiry against ssldays or similar services.

1. DNS and SNI fidelity. Targets use public hostnames users type, with modules that send correct Server Name Indication.
2. Probe network location. Scrapers inside VPC may not see CDN edge certs customers hit.
3. Target hygiene process. Merge requests or automation add new public names before launch day.
4. Registrar monitoring. RDAP or acknowledged gap for each TLD you operate.
5. Alert thresholds. 30/14/7/1-day runway with noise control after successful renew.
6. Operational load. Hours spent tuning rules vs dollars for managed monitors at your host count.
7. Webhook ergonomics. Slack/Discord without standing up Alertmanager bridges manually.
8. Scrape interval economics. Hourly polls across thousands of hosts cost CPU and cardinality.
9. Incident debugging. One-click live check for stakeholders without kubectl access.
10. Second opinion. Monthly diff between Blackbox notAfter and external handshake on sample hosts.

Minimal scrape snippet teams recognize:

scrape_configs:
  - job_name: blackbox-https
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://www.example.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Validate modules against vendor docs—http_2xx must negotiate TLS you intend to measure.

How ssldays compares

Operate Blackbox for platform metrics and SLO culture. Layer ssldays on business-critical and agency hostnames where target files rot, or where RDAP should sit beside TLS without you writing RDAP clients.

ssldays performs live TLS reads—issuer, SANs, chain trust, expiry—and optional registrar dates. Alerts at 30, 14, 7, and 1 days, once per threshold per renewal cycle. Email everywhere; Slack and Discord webhooks on Starter and Pro. Free: 3 domains, daily; Starter: 25, hourly; Pro: 100, hourly.

Run a quarterly script: sample ten hosts, compare Blackbox days-remaining with ssldays; investigate outliers before they become customer screenshots. Feed ssldays alerts into the same Slack routes Alertmanager already uses.

For visualization, pair with Grafana SSL dashboards. For wider DIY context, see open-source SSL expiry monitors.

Common mistakes

Scraping origin URLs while users hit CDN cnames. Edge and origin expire independently.

Using insecure_skip_verify: true to silence alerts. You measure connectivity, not trust customers expect.

Alerting only when days < 7. No time for manual OV renewals or CAB approvals.

Cardinality explosion labeling every redirect hop. Monitor the canonical customer hostname instead.

Forgetting to reload after cert-manager renews. Metrics show new secret while edge still serves old serial—exactly why external presentation checks matter.

Next steps

Review Blackbox target files against your public DNS inventory. Delete stale hosts; add missing API and marketing names.

Run each gap through live check. Fix Prometheus targets where they should match, or import into ssldays when another team owns the name.

Promote Blackbox recording rules to production only after a burn-in week comparing alert noise with ssldays email on the same set.