Alerts & Notifications

CertTracker sends proactive emails so your team learns about a problem before it becomes a customer-facing one. This article covers every alert type, who they go to, how to control the routing, and how to test the whole pipeline without waiting for something to actually break.

The five alert types at a glance

Expiration alerts

CertTracker uses an escalating cadence — quiet far out, increasingly noisy as the cert approaches expiry:

The threshold is per-monitor. Open the edit pencil (✏️) on any monitor and set Expiry threshold (days) — defaults to 30. Raise it for certs you want extra runway on. The escalating cadences (8–30 weekly, 2–7 daily, final 24h hourly) always apply once you cross into those windows, regardless of the threshold you set.

Expiration emails cannot be turned off while the monitor exists. If you don't want them, pause the monitor.

Change alerts

When the leaf certificate's SHA-256 fingerprint changes between two successive polls, CertTracker:

1. Records the change in the monitor's history
2. Flips the monitor's status pill to Changed
3. Sends an alert email with a before/after comparison of every field that moved (issuer, validity dates, fingerprints, SANs, etc.)

The email stays repeating once every 24 hours until somebody acknowledges it. From the email or the monitor detail modal in the portal, click Mark as Expected (the change was a planned renewal/rotation) or Acknowledge as Issue (the change is suspicious and needs investigation). Either action stops the repeating email.

Availability alerts (Business & Enterprise)

For monitors on Business or Enterprise plans set to a 5-minute polling interval, CertTracker tracks reachability separately from cert validity. Below Business or above 5-minute intervals, availability is collected but not surfaced as an alert.

The cadence:

Advisory alerts (opt-in)

Four advisory categories detect TLS misconfigurations beyond just expiration: weak cipher / deprecated protocol, weak signature algorithm, excessive validity period, and hostname mismatch. They're detected on every poll and stored, but emails are off by default per company.

Turn them on via Administration → Alert Addresses → Manage Advisory Alerts — independent toggles for each category. Once enabled, advisories digest at most once per day per monitor until they're resolved at the endpoint or acknowledged in the monitor detail modal. Multiple advisories on one monitor coalesce into a single digest email.

Full details on each check live in the What CertTracker Checks article.

Who receives alerts

Two layers determine who gets emailed when an alert fires for a given monitor:

1. The company-wide alert recipients list lives at Administration → Alert Addresses. Recipients here are not user accounts — they're email-only destinations (distribution lists, on-call inboxes, manager addresses). They receive alerts for monitors that have them assigned.

2. Per-monitor recipient assignments (Pro plan and up) let you target alerts narrowly. On the per-monitor edit pencil, the Alert Recipients field shows which of your company's recipients are assigned to that specific monitor — only those recipients get notified when an alert for that monitor fires.

Why two layers? So the auth team gets paged about the auth stack's certs, the billing team gets paged about the billing stack's certs, and nobody's inbox is full of alerts that aren't theirs.

Group / stack alerting (the differentiator)

Most certificate monitors treat each cert as a property of one device. CertTracker treats the cert as a property of the service — and one service can span multiple monitors (load balancer + N origin servers + a CDN endpoint, all serving the same cert). Combine two existing features and you get group alerting that follows the stack, not the host:

1. Tag the stack. Open the monitor inventory, filter to the monitors that belong together, click ✏ Bulk → Tags → type the stack name (e.g. auth-stack) → + Add to all. Every monitor in the filter view now carries that tag.

2. Route the recipient. With the same auth-stack filter still applied, open ✏ Bulk again → Alert Recipients → pick Auth Team from the dropdown → + Add to all. Every monitor in the auth stack now alerts the auth team.

When a cert on any monitor in the stack expires, changes, goes down, or triggers an advisory, the auth team gets the email. Nobody else's inbox lights up.

To re-org later (auth-stack moves to a different team, or you split it into two stacks), re-filter and re-bulk. − Remove from all strips a recipient or tag as cleanly as add applies them.

Managing alert addresses

Add an address: Administration → Alert Addresses → Add Alert Address → enter name + email → Save. The address starts receiving alerts immediately for any monitors it's assigned to.

Remove an address: click the recipient in the list, then Delete in the popup. The address stops receiving alerts immediately. Per-monitor assignments are cleaned up via cascade.

Disable temporarily: clicking the recipient and toggling Enabled off keeps the recipient (and all per-monitor assignments) but suspends delivery. Useful when someone's on vacation.

Send Test Notification

The fastest way to confirm alerts work end-to-end (SMTP, recipient list, template rendering) is the Send Test button on the Alert Addresses card:

1. Pick a recipient from your list.
2. Pick the notification type — Expiry Warning, Certificate Changed, Availability Down/Recovery, or any of the four advisory categories.
3. Optionally pick a specific monitor (synthetic example.com values are used if blank).
4. Click Send Test.

The email lands in the recipient's inbox with [TEST] prefixed on the subject line. No database rows are written; the live notifier state is unaffected.

What the alert email contains

All alert emails include:

• Subject line — alert type, hostname, urgency where relevant
• Endpoint identity — company, hostname, port
• Status snapshot — current certificate / availability state
• Direct-link button — opens the monitor detail modal in the portal, deep-linked to the row in question
• Change details (change alerts only) — before / after comparison of every changed field
• Acknowledge buttons (change alerts, advisory alerts) — one click to mark Expected, Issue, or Acknowledged

Delivery troubleshooting

If alerts aren't arriving:

• Check spam. Add the configured sender address to your allowlist.
• Check the recipient is enabled under Administration → Alert Addresses.
• Check the per-monitor assignment. On Pro and up, a recipient that's in your company's list but not assigned to the monitor in question won't get that monitor's alerts. Use ✏ Bulk to assign in batch.
• Check /logs/auth. Login/lockout events filter there, but if you suspect a deliverability issue contact support — they have access to the notifier's stderr stream.

Pro tips

• Pause noisy monitors during planned work. A scheduled cert rotation will fire a change alert; pause the monitor before the rotation, resume after. Pausing also suspends expiration alerts for the same monitor.
• Raise the expiry threshold on long-validity internal CAs. Default of 30 days is sized for public CAs with ~90 day validity. For a 3-year internal cert, 60–90 days of runway is more useful.
• Use a dedicated address for advisory alerts. Advisory categories tend to be lower urgency than expiration. Routing them to an infra-advisories@ address (different from your on-call) keeps the urgent stuff signal-strong.
• Test before you trust. Run Send Test to every recipient address after any SMTP or DNS change. Cheaper than discovering a misconfigured MX during a real incident.