# Using shortlived in Prod **URL:** \ **Category:** Help\ **Created:** [January 13, 2026, 2:34pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550 "2026-01-13T14:34:57Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Timmay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/timmay/32/80032_2.png) [@Timmay](https://community.letsencrypt.org/u/Timmay)\ **Post date:** [January 13, 2026, 2:34pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/1 "2026-01-13T14:34:57Z")
My domain is: timslab.fun Hi Folks, I recently realized that LE is issuing me real certs from Prod that are shortlived! COOL! I want to make sure I'm not going to hit the rate limiter. My assumption is that I should renew \ new order every 2 - 3 days. The rate limiting guide says: > **[Rate Limits](https://letsencrypt.org/docs/rate-limits/)** > > Let’s Encrypt provides rate limits to ensure fair usage by as many people as possible. We believe these rate limits are high enough to work for most people by default. We’ve also designed them so that renewing a certificate almost never hits a rate... - Up to 5 certificates can be issued per exact same set of identifiers every 7 days. - The ability to request new certificates for the same exact set of identifiers refills at a rate of 1 certificate every 34 hours. My belief is that if I request a cert with the exact set of identifiers every 48 - 72 hours I should never hit the rate limiter. Is every 48 - 72 hours a good recommendation for new certificates when using shortlived in LE Prod? Thanks!! Tim ---
**Author:** ![xlionjuan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/xlionjuan/32/87121_2.png) [@xlionjuan](https://community.letsencrypt.org/u/xlionjuan)\ **Post date:** [January 13, 2026, 2:46pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/2 "2026-01-13T14:46:17Z")
If you follow the ARI time window, you won't get rate limited If your ACME client haven't support ARI, I suggest to hold on. You could use `tlsserver` profile to get some extra benefits and don't need to worry about ARI for now. ---
**Author:** ![Maiyannah](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/maiyannah/32/90296_2.png) [@Maiyannah](https://community.letsencrypt.org/u/Maiyannah)\ **Post date:** [January 13, 2026, 2:55pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/3 "2026-01-13T14:55:41Z")
I just put it on a cron job for the 10th of each month and that seems fine. Itll be going to 45 days, so checking every month should be fine. ---
**Author:** ![Timmay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/timmay/32/80032_2.png) [@Timmay](https://community.letsencrypt.org/u/Timmay)\ **Post date:** [January 13, 2026, 2:58pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/4 "2026-01-13T14:58:51Z")
I'm using ansible and the community.crypto.acme\_certificate module. > **[community.crypto.acme\_certificate module – Create SSL/TLS certificates with...](https://docs.ansible.com/projects/ansible/latest/collections/community/crypto/acme_certificate_module.html)** As far as I can tell this ACME client does not support ARI. I've read about and understand what ARI is and does. > **[ARI Renewals - Rate Limits](https://letsencrypt.org/docs/rate-limits/#ari-renewals)** > > Let’s Encrypt provides rate limits to ensure fair usage by as many people as possible. We believe these rate limits are high enough to work for most people by default. We’ve also designed them so that renewing a certificate almost never hits a rate... > **[An Engineer’s Guide to Integrating ARI into Existing ACME Clients](https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients)** > > Following our previous post on the foundational benefits of ACME Renewal Information (ARI), this one offers a detailed technical guide for incorporating ARI into existing ACME clients. > Since its introduction in March 2023, ARI has significantly... At this point I'm more concerned about hitting the rate limiter. xlionjuan said \>\> I suggest to hold on. I ask why? Maiyannah, last night I put a cron job to request a new shortlived every 48 hours since I believe that should not hit the rate limiter. I'm posting here in hopes that we get some official guidance. Thanks!! ---
**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:** [January 13, 2026, 3:05pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/5 "2026-01-13T15:05:05Z")
> [@Maiyannah](#): > > I just put it on a cron job for the 10th of each month and that seems fine First, that is very poor practice for any LE cert renewal. I'll get back to that in a later post. But, the short-lived certs have a lifetime of 6+ days so wouldn't work for this thread. @Timmay Renewal should be based on ARI with perhaps a fallback of less than half their life left. See this LE topic: [Integration Guide - Let's Encrypt](https://letsencrypt.org/docs/integration-guide/#when-to-renew) You might also consider having a fallback plan for a different CA when using short-lived certs. An extended outage at LE might cause a short-lived cert to expire leading to outages for you. Just a compatibility problem with your ACME Client and LE could cause the same kind of problem so having another CA on standby is sensible. Please also review the short-lived profile docs: [Profiles - Let's Encrypt](https://letsencrypt.org/docs/profiles/#shortlived) Especially note this: "We recommend this profile for those who fully trust their automation to renew their certificates on time. This profile is not for everyone." I am not familiar with your ACME Client but can't it check the cert lifetime and renew only when it reaches a certain threshold? Many clients have such a setting. That allows them to run often (like twice or three times / day) and they renew only when the cert is close to threshhold. ---
**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:** [January 13, 2026, 3:18pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/6 "2026-01-13T15:18:22Z")
> [@Maiyannah](#): > > I just put it on a cron job for the 10th of each month and that seems fine. Checking (or trying) a cert renewal just once a month is not advised. This is especially problematic as cert lives are reduced to 45 days. In that case just one cert request failure will result in an expired cert on your server. For 90 day certs, if you are forcing renewal every 30 days that is twice as often as needed and using LE resources. And, only a small number of sequential failures can result in an expired cert. LE has never recommended that practice. A well-written ACME Client should be able to run once or twice a day. It should check ARI to know when to renew. If ARI fails (or is not supported by your ACME Client), a fallback plan to renew as cert life is than half remaining for short-lived certs (6+ day) and just one-third left for other certs. The ACME Client can assess the cert on your local system so there is little cost to checking this frequently. ARI requests do require occasional HTTP requests but LE's ARI servers are designed for especially high-volume requests. ARI uses a retry-after response header to throttle incoming requests. Update: Another reason for more frequent checks is to respond to CA revocation events. It is rare but Let's Encrypt may need to revoke your cert for various reasons. ARI will notify your ACME Client about this so it can renew immediately. But, if you aren't checking ARI often your cert can become expired. When LE still ran OCSP servers an ACME Client could run frequently and check OCSP for that. But, ARI has been around fairly long now and ACME Clients should be supporting it. ARI is supported by a wide variety of CA and is an RFC. ---
**Author:** ![xlionjuan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/xlionjuan/32/87121_2.png) [@xlionjuan](https://community.letsencrypt.org/u/xlionjuan)\ **Post date:** [January 13, 2026, 3:44pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/7 "2026-01-13T15:44:48Z")
> [@Timmay](#): > > xlionjuan said \>\> I suggest to hold on Because renew in the ARI window will bypass the rate limit, but if not, and your ACME client accidentally exceeded the limit and you don't know, your certs will expired. ---
**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:** [January 13, 2026, 4:43pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/8 "2026-01-13T16:43:13Z")
> [@xlionjuan](#): > > Because renew in the ARI window will bypass the rate limit In early days of ARI that was discussed but I believe the more important element is that the ACME Client use the "replaces" option for the cert ID that it gets from ARI. See this renewal section: [Rate Limits - Let's Encrypt](https://letsencrypt.org/docs/rate-limits/#limit-exemptions-for-renewals) It's possible a cron or timer based ACME Client might renew after the ideal ARI window but still be able to use "replaces" to avoid rate limits. At least that's how I read these docs. A well-behaved and properly configured Client would normally run within the window at least as how Let's Encrypt has them now. The ARI window is in the past for CA revocation events. And, may be in the past in the future for CA load balancing or planned outages. So, I think "replaces" is all that is needed to avoid rate limit not the window. ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [January 13, 2026, 5:08pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/9 "2026-01-13T17:08:34Z")
> [@MikeMcQ](#): > > So, I think "replaces" is all that is needed to avoid rate limit not the window. It's actually _both_: > The second return value is a boolean indicating whether the order is exempt from rate limits. If the order is a replacement and the request is made within the suggested renewal window, this value is true. Otherwise, this value is false. > Looking through the code, "within the window" is really what it says: Current time must be after the window start, but also before the window end. So if the ARI window has already passed, you're no longer exempt from rate limits. (Also, if you're renewing way too early, you're not exempt either) This brings up an interesting question: For incidents, LE returns ARI windows intentionally [set to the past](https://github.com/letsencrypt/boulder/blob/37e834bab73cd4749ba0ee0d9d90dfcf23677458/core/objects.go#L466): Apparently those are **not** exempt from renewals, which sounds like an oversight? ---
**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:** [January 13, 2026, 5:14pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/10 "2026-01-13T17:14:53Z")
> [@Nummer378](#): > > Apparently those are **not** exempt from renewals, which sounds like an oversight? Also an oversight that the Rate Limits page does not mention ARI window requirement 🙂 ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [February 12, 2026, 5:15pm UTC](https://community.letsencrypt.org/t/using-shortlived-in-prod/244550/11 "2026-02-12T17:15:46Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.