Is the certificate right, or just right for you?

Opens a real TLS connection to your site and reads the certificate the server presents, the chain it serves with it, and which TLS versions it will agree to. It is not a lookup in somebody's database: it is the handshake, which is why it can tell you about a chain that works in your browser and fails on a phone.

A server should send its certificate and the intermediate certificate above it. If it only sends its own, your browser may still succeed — because it cached that intermediate from another site — while a phone that has never seen it fails. This is one of the most common real causes of “it works for me”, and it is invisible until somebody checks the chain as served.

Thirty is the usual alarm and fourteen is late. Automated renewal (Let's Encrypt and most platforms) renews around thirty days out, so a certificate inside two weeks usually means the renewal is failing rather than that nobody has got around to it. Shopify and most hosts handle this for you; a custom domain in front of a custom server is where it goes wrong.

A header that tells browsers to refuse plain HTTP for your domain for a stated period. It closes the gap where a visitor's first request goes out unencrypted and can be intercepted. Worth having, with one caution: a long max-age is hard to undo, so start short.

Yes, and not because anybody uses them: the browsers dropped them in 2020 and PCI DSS does not accept them. If your server still offers them, there is nothing to gain and a line in an audit to lose. Turning them off is a configuration change, not a migration.

No — it checks it now, and a certificate expires on a date nobody has in their calendar. That is what Bilby does: it looks at the certificate, the domain's expiry and the whole buying path every night, and emails you before the date rather than after.