OCSP — Revocation Status and Whether Stapling Works
This checks whether a certificate has been revoked and, more usefully in practice, whether the server staples that status into the TLS handshake. Stapling means the server fetches the revocation response itself and includes it, so the client does not have to make its own request to the certificate authority.
Why run it
Because stapling failures are common and their cost is invisible from the server side. Without a stapled response, every client that checks revocation makes a separate request to the authority mid-handshake — adding latency to your visitors' first connection, and telling a third party which sites they are visiting. Stapling silently stops working for ordinary reasons: the server cannot reach the responder, a cached response has expired and not refreshed, or a configuration change dropped it. Nothing fails, so nothing is reported.
Why automate it
The failure has no symptom, which is the entire argument. Connections still succeed, certificates are still valid, and monitoring reports everything healthy while your handshakes are slower than they should be and your visitors' browsing is being disclosed. Only a check that specifically looks for the stapled response detects it. Scheduling it alongside certificate expiry is natural, since both are properties of the same handshake and both regress after the same kinds of change.
What it gives you
Detection for a performance and privacy regression that produces no errors and appears in no dashboard. It also gives independent confirmation that a certificate you are serving has not been revoked.