SSL & certificates
Every HTTPS check captures the served certificate in parallel with the main request and surfaces days remaining until expiry on the endpoint detail page. When that count drops below your warning window, the run flips to degraded and an incident opens once the failure threshold is reached.
What WatchDeck checks
- Days until expiry, derived from the certificate’s
validTofield.
That’s it. SSL monitoring on WatchDeck is intentionally narrow.
What WatchDeck does not check
To make sure cert capture works against staging environments, custom CAs, and self-signed setups, the TLS connection that captures the cert is opened with rejectUnauthorized: false. As a side-effect, none of the following are validated:
- Chain validity — a cert signed by an untrusted root will still get its expiry checked.
- Hostname match — a cert for
wrong-name.comserved onyour-app.comwon’t fail this evaluator. - Revocation (OCSP/CRL) — never queried.
If your browser shows a certificate warning, WatchDeck will still report “healthy” so long as the cert hasn’t expired. Use a separate audit (e.g. SSL Labs) for chain and hostname validation.
This is a deliberate scope choice for the early product, not an oversight. If trust-chain monitoring matters for your deployment, open an issue on the WatchDeck repository so we can prioritise it.
Configuring the warning window
In the Monitoring section of the add-endpoint form (or the matching Settings tab on an existing endpoint), pick a value for SSL warning window:
| Preset | Behaviour |
|---|---|
| Off | Disable the SSL evaluator on this endpoint. Pass 0 (or any non-positive value). |
| 7 days | Warn one week out — tight, only if you have automation re-issuing certs. |
| 14 days | Default. Aligns with Let’s Encrypt’s typical re-issue cadence. |
| 30 days | Comfortable buffer for most teams. |
| 60 days | Conservative — useful if cert rotation goes through a procurement step. |
| 90 days | Maximum preset — suitable for one-year certs. |
Expired vs. expiring
When a cert is about to expire (days < sslWarningDays), the evaluator returns degraded with a reason like "Certificate 5 days remaining (warn at 14 days)".
When a cert has already expired (days <= 0), the evaluator still returns degraded, not down. The reason is that the underlying HTTPS request can still succeed against an expired cert (because of rejectUnauthorized: false). Browsers will reject it, but WatchDeck’s check engine connects and reports the response. Treat this state as urgent — even though the verdict is degraded, customer browsers are seeing the warning.
Overriding via an SSL assertion
For finer control, add a kind: 'ssl' assertion. It uses the same days-remaining input but lets you pick:
- A different operator (
lt,lte,gt,gte,eq). - A different severity — set it to
downif you’d rather page on cert expiry instead of just colouring the dashboard.
When an ssl assertion exists on an endpoint, it supersedes the Monitoring-tab warning window — the assertion’s threshold and severity take effect, and the warning-window field becomes informational only.
HTTPS only
The SSL evaluator runs only when the endpoint URL begins with https://. For TCP / port checks and plain http:// URLs, the field is hidden and no cert is captured.
What’s next
- Add an
sslassertion when the defaultdegradedseverity isn’t strong enough. - Wire a notification channel so cert-expiry incidents reach you before the cert does.
- Troubleshooting → SSL warning fires but my cert is fine for common false-positive scenarios.