The value is different for every cert; the retry header is currently coded to 6 hours from the ARI request, and the ARI response is 2/3 of the cert life. I believe ISRG caches the response to handle the potential of clients that do not respect the header (advised by the RFC).
I interpreted the docs about "sleep" to mean a process or messaging queue that is only concerned with a single certificate. For a client handling multiple certificates, that recommendation becomes difficult to follow, especially as the dominant model for current clients is a script invoked by cron.
I just wanted to share this other bit from the draft, again with emphasis added:
Server choice of Retry-After
Servers set the Retry-After header based on their requirements on how quickly to perform a revocation. For instance, a server that needs to revoke certificates within 24 hours of notification of a problem might choose to reserve twelve hours for investigation, six hours for clients to fetch RenewalInfo, and six hours for clients to perform a renewal. Setting a small value for Retry-After means that clients can respond more quickly, but also incurs more load on the server. Servers should estimate their expected load based on the number of clients, keeping in mind that third parties may also monitor RenewalInfo endpoints.
This 24 hour revocation period is the CA/B forum timeline for critical revocation (e.g. compromise), other methods (such as mass revocations) have 5 days. IMHO, due to implementation details of the TLS ecosystem, a certificate is unlikely to cause issues within 48 hours of revocation. A browser vendor may use proprietary channels to push this through quickly.
I've managed and advised highly trafficked websites that were constant security targets, and they should implement continuous ARI polling now to catch that retry window. Investing the resources on early adoption is a good option for them.
I think most other subscribers will be fine with a short delay. Remember, this is offering a new warning system so any improvements are a net benefit against the current status quo of absolutely no warning at all.
I think my point above got lost in the language. For a client managing multiple certificates, the Retry-After will be different for each certificate as they are based on the query time; and the server can change their recommended logic at any point - a conformant client and integration needs to be prepared for that. LetsEncrypt might decide that 24 hours is fine, or drop it 3.
Utilizing the "retry-after" as a target would mean deploying a messaging/dispatch system or using a daemonized process. Most ACME clients are invoked through commandline interfaces for a short lifecycle, so periodic task runs are the only option. This will start to segment the retry-afters into different buckets.
There is also the concern that rety-after could shift based on certificate type; we are expecting 6 hours because that is currently hardcoded into Boulder - but ISRG might decide on different retry protocols for different profiles.
TLDR; Actually utilizing the retry-after as the target is a lot of work with minimal payoff.