Ignisfox
Walkthrough

SSL monitor

The SSL monitor watches public hostnames and tells you when their certificates are about to expire, have already expired, or start serving the wrong material. Manage hosts at /dashboard/monitor; configure alert delivery at /dashboard/settings/alerts.

Adding hosts

Drop a hostname (and optional non-443 port) into the Add form. Any public TLS endpoint works — bare hostnames like api.example.com, non-default ports like mail.example.com:993, or wildcards resolved to a specific host. IP literals work but SAN matching will almost always fail.

Labels are purely cosmetic — useful when you monitor the same hostname on a few ports or behind different edges and want to tell them apart in alerts.

What the probe checks

On every probe (manual or scheduled) we open a single outbound TLS connection to the host and extract the leaf certificate. Four checks run against it:

  • TLS handshake — does the server actually speak TLS on that port, and does a negotiation complete? Connection refused / protocol errors count as a hard fail.
  • Certificate expiry — we read notAfter from the leaf and compute days-remaining. Under 30 days trips a warning, under 0 days is an error.
  • SAN match vs hostname — the hostname you added has to appear in the cert's Subject Alternative Names (or Common Name as the legacy fallback). Wildcards are respected per RFC 6125. A mismatch is an error regardless of expiry.
  • Chain completeness — the server should serve the leaf plus every intermediate up to (but not including) the root. Missing intermediates trigger a warning; the cert is still "valid" but half your clients will fail to build a path.

Status values

Every host ends up in one of three states after its most recent probe:

  • ok — all four checks passed and the cert has more than 30 days left. The monitor list shows a green dot.
  • warn — one or more soft issues: under 30 days to expiry, or an incomplete chain. Amber dot. The cert still works today but you should act before it bites.
  • error — a hard issue: expired, SAN mismatch, handshake failure, or connection timeout. Red dot, email fired. A cert in this state is actively breaking clients.

Scheduling

Each tenant has a probe_cron_expr — a cron expression that controls how often the full sweep runs. Default is 0 2 * * * (daily at 02:00 local time). Change it in the Schedule panel on the monitor page. See Cron schedules for the semantics — in particular, the global ticker is hourly so sub-hour cadences get rounded up to the next tick.

You can also click Probe now on any row for an on-demand probe — useful right after a cert rotation when you want to confirm the new material made it out to production.

Probe timeouts

Each probe has a hard ceiling of 10 seconds: 6 seconds for TCP connect, 4 seconds for the TLS handshake itself. Anything slower is recorded as a timeout error — that includes servers with aggressive rate limiting, captive portals, or a firewall silently dropping SYNs. This keeps the cron worker under Vercel's 60-second function cap even when a batch of hosts go unhealthy simultaneously.

The scheduler processes up to 8 hosts concurrently per tick, so a 10s timeout per host still lets ~480 hosts complete in the worst case within one ticker window.

Email alerts

Alerts fire on status transitions, not on every probe. If a host goes ok → error you get one email. If subsequent probes also return error, you get silence — no spam for the same issue. When the cert is fixed and the next probe flips back to ok, you get a recovery email.

Which transitions generate email, and which address receives them, is configured at /dashboard/settings/alerts. You can scope alerts to specific status changes (e.g. only on → error, ignore ok-to-warn chatter) and override the destination address per tenant.

Reading the detail panel

Click a host row to expand it. You'll see the full certificate: issuer, SAN list, valid-from / valid-to, serving IP, and the most recent error message if the probe failed. This is often enough to diagnose the issue without even SSH'ing into the server:

  • Hostname mismatch — the wrong vhost is being served, usually because SNI routing changed.
  • Unable to verify the first certificate — intermediate chain is missing. Concatenate the chain into the bundle on the server.
  • ECONNREFUSED — the port isn't open at all. Service down, firewall, or configuration drift.

Removing a host

Hit Delete on the row. The probe history and alert state are removed along with it. If you only want to pause alerting without losing history, unsubscribe from alerts for that host at /dashboard/settings/alerts instead.

Limits

  • Free tier — up to 5 monitored hosts.
  • Starter — up to 50.
  • Team — up to 500.
  • Enterprise — unlimited with bespoke concurrency tuning.