How to see when a HSTS domain is about to expire?

HSTS data is kept by each web browser.

When a request is made to a domain that implements HSTS, the response headers will contain a Strict-Transport-Security header that notes the maximum age of the record and optionally some other HSTS-related values.

This maximum age effectively gives a time-to-live starting at the time when the response is received.

This is illustrated, though not explicitly spelled out, by RFC 6797 section 11.2 (non-normative), which states:

The "constant value into the future" approach can be accomplished by constantly sending the same max-age value to UAs.

and

The "fixed point in time" approach can be accomplished by sending max-age values that represent the remaining time until the desired expiry time. This would require the HSTS Host to send a newly calculated max-age value in each HTTP response.

So if a domain has used HSTS in the past, then in a situation where the HSTS max-age has not been changed previously, the earliest time when no client can be expected to rely on old HSTS data is the time of the last request that returned HSTS data, plus the time that was stated in that HSTS data at that time. If the HSTS max-age has been lowered, then these time periods form sliding windows; that which ends last is the earliest time when no client can be expected to rely on old HSTS data. This is a consequence of one of the requirements in section 8.1.1 (normative):

A Known HSTS Host is "expired" if its cache entry has an expiry date in the past. The UA MUST evict all expired Known HSTS Hosts from its cache if, at any time, an expired Known HSTS Host exists in the cache.

On any request, if the response is received over a secure transport and includes HSTS data, then as stated in section 8.1, the client UA must update its list of known HSTS hosts (normative):

If /.../ the UA MUST [either]: /.../

• Update the UA's cached information for the Known HSTS Host if either or both of the max-age and includeSubDomains header field value tokens are conveying information different than that already maintained by the UA.

  The max-age value is essentially a "time to live" value relative to the reception time of the STS header field.

As a consequence, turning on HSTS is effectively a promise to keep offering valid HTTPS for no less than the duration of the max-age HSTS parameter, counting from the moment of the response.

As a further consequence, there is no fixed "expiration" date and time for HSTS data unless the server uses the "fixed point in time" approach described non-normatively in the RFC.

HSTS is set through the use of a HEADER, Namely Strict-Transport-Security: max-age=31536000 where the max-age defines how long the browser is going to remember the HSTS setting, since last time it first saw this HEADER. (atleast that is how I understand it). When the Max-Age is up the browser will redo the HSTS only if the header is again there in the request.

Common practice is to put the Max-Age at 1 year (in seconds). It is considered good practice for any TLS web page to include this header with a long Max-age, so clients know the site is supposed to be TLS and will even remember it, so MitM attacks have fewer open attack vectors.

Edit: Since the list of HTST websites is a browser specif thing, where this is set, when its set and how to find out about expiry is browser specific. and is without further details out of scope due to missing information (e.a. what broser). to list them all would be a bit long-winded and version sepcific in a lot of cases.