Every HTTPS monitor tracks its certificate expiry automatically. There is nothing extra to configure and nothing extra to pay for. Branch on days remaining in a policy and the warning arrives while there is still time to act.
The expiry date is read as part of the normal check. You do not create a separate monitor or enable an extra feature.
The current countdown appears alongside response time and uptime on the monitor, so it is part of the picture rather than buried.
An if / else branch offers "certificate expiring within N days" as a condition, which means renewal warnings use the same policy machinery as outages.
Route the warning wherever it will actually be seen: a channel, a named engineer, a Jira ticket that becomes a scheduled task.
Most certificates renew themselves now, which is exactly why the failures that do happen catch people off guard.
A renewal job that stops working gives no signal until the certificate actually expires. A countdown notices the gap; the job cannot report its own absence.
Vendor endpoints, partner APIs and appliances with manual certificates are the ones most likely to lapse and least likely to be watched.
An expired certificate does not degrade a service. Every browser and client rejects it at once, and the fix takes longer than the warning would have.
The check costs nothing extra because it rides along with a monitor you already wanted.
Add an HTTPS monitor, branch on certificate days remaining, and stop finding out from a customer.