# What are you doing with ARI Retry-After? **URL:** \ **Category:** Client dev\ **Created:** [February 3, 2025, 2:38pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048 "2025-02-03T14:38:53Z")\ **Posts on this page:** 9\ **Page:** 2
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [February 3, 2025, 9:18pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/21 "2025-02-03T21:18:03Z")
> [@MikeMcQ](#): > > If you only run every 12H, or even 6H or whatever it isn't much help to look at the prior target time from Retry-After. Just make fresh ARI request and react to suggested start time. Makes sense if the `Retry-After` interval is also 6 hours. But if you run your ACME client more often, i.e., every 2 to 4 hours, then you could use the header. And I see the whole `Retry-After` being a "target" thing more as something like `if $time > $retry-after then do_stuff else do_nothing`. Not sure why you'd need to run the ACME client at _exactly_ the target timestamp. ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [February 3, 2025, 9:24pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/22 "2025-02-03T21:24:56Z")
> [@Osiris](#): > > Not sure why you'd need to run the ACME client at _exactly_ the target timestamp. I think the main reason would be if the CA is trying to reduce (or spread out) load on their ARI-serving system. So if every client checked ARI at exactly midnight due to poor default schedules, having some way for the ARI server to tell the client to do their next check at some time, spread out, might be helpful? ARI is supposed to be easy for CAs to just offload to their CDN caches, but I could see wanting the specification to push clients toward following server recommendations just in case it turns out that servers are smarter about when they should be queried next than the clients are. Just a guess as to what might be the motivation. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [February 3, 2025, 9:35pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/23 "2025-02-03T21:35:20Z")
> [@Osiris](#): > > Not sure why you'd need to run the ACME client at _exactly_ the target timestamp. The concern is the spec says to treat it as a target and be prompt at refreshing ARI info. Draft 7 is much different than Draft 3. To be a "good" client means we SHOULD do something. So, the question revolves around what this means in practice. Draft 7 > Note that in other HTTP applications, Retry-After often indicates the earliest time to retry a request. In this protocol, it indicates both the earliest time and a target time. and > 4.3.2. Client handling of Retry-After > > After an initial fetch of a certificate's RenewalInfo, clients SHOULD > fetch it again as soon as possible after the time indicated in the > Retry-After header ... ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [February 3, 2025, 9:42pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/24 "2025-02-03T21:42:50Z")
> [@MikeMcQ](#): > > as soon as possible This is open for interpretation. Or not even that: if I run my client every 2 hours, the next run would be "as soon as possible". ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [February 3, 2025, 9:56pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/25 "2025-02-03T21:56:59Z")
> [@Osiris](#): > > open for interpretation Sure. But, you can see the changes in the draft I pointed out earlier. It went from specifically talking about what cron-based clients should do to saying only be driven by retry-after. To be clear about my opinion ... even a cronjob running once or twice daily and checking ARI renewal window is far ahead of what we've had to date. ARI is a big improvement. I think we'll need to wait for further clarification from the CA's as to best practice for cron-based clients though. And, of course the experience gained from the usual bruises and bandages from being at the leading edge 🙂 ---
**Author:** ![webprofusion](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/webprofusion/32/85310_2.png) [@webprofusion](https://community.letsencrypt.org/u/webprofusion)\ **Post date:** [February 4, 2025, 2:51am UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/26 "2025-02-04T02:51:40Z")
Currently in Certify The Web we set our own schedule for ARI checks (12 hrs) for our own convenience because we also check OCSP in the same batch, we will probably eventually use the server provided RetryAfter. Keep in mind when accepting 3rd party suggestions that affect your own process that they may (for instance) inadvertently cause all certs to become due for renewal, which may exceed practical limits depending on scale. We don't necessarily honor the Suggested Start/End of renewal if we would have renewed earlier than the suggested window, because ultimately the user, not the CA, controls that preference. ---
**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\ **Post date:** [February 4, 2025, 9:22pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/27 "2025-02-04T21:22:21Z")
From the perspective of the ARI author, the ideal ACME client wakes up every hour, but only has to do local work most of the time: checking the latest ARI response to see if it's in the suggested window now, checking the latest retry-after to see if it needs to check again, checking the certs on disk to see if one has expired, checking the local config to see if there's a new cert to manage, etc. It only does "real" work if one of those checks says it needs to, so waking up that frequently is cheap. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [February 4, 2025, 10:14pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/28 "2025-02-04T22:14:51Z")
> [@aarongable](#): > > the ideal ACME client wakes up every hour That's helpful. Thanks > [@aarongable](#): > > checking the certs on disk to see if one has expired And that too but I'd seen that on an earlier thread 🙂 ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [March 6, 2025, 10:15pm UTC](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048/29 "2025-03-06T22:15:29Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed. [Previous page](https://community.letsencrypt.org/t/what-are-you-doing-with-ari-retry-after/233048.md?page=1)