# Redis cache stats entries - time to live

**URL:** <https://discuss.hangfire.io/t/redis-cache-stats-entries-time-to-live/9866>\
**Category:** question\
**Tags:** redis\
**Created:** [April 6, 2023, 3:48pm UTC](https://discuss.hangfire.io/t/redis-cache-stats-entries-time-to-live/9866 "2023-04-06T15:48:09Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Anthony\_Hawkley](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/anthony_hawkley/32/3267_2.png) [@Anthony\_Hawkley](https://discuss.hangfire.io/u/Anthony_Hawkley)\
**Post date:** [April 6, 2023, 3:48pm UTC](https://discuss.hangfire.io/t/redis-cache-stats-entries-time-to-live/9866/1 "2023-04-06T15:48:09Z")

</div>

I’m using Hangfire Pro with a Redis backend - it’s great, but can get spendy pretty fast so I am trying to persist as little as possible.  
I have all my batches and jobs expiring in an hour (TTL), which seems to be the minimum, but I have stats entries that have a time to live of 30 days - anyone know how to get set stats TTL to a lower value?

Thanks!

 ![image](https://europe1.discourse-cdn.com/flex017/uploads/hangfire/original/2X/3/3fddcf7a09086f2065a7f48d39de28d0b38974c5.png)

---

<div class="post-metadata">

**Author:** ![VagyokC4](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/vagyokc4/32/3291_2.png) [@VagyokC4](https://discuss.hangfire.io/u/VagyokC4)\
**Post date:** [April 28, 2023, 3:09am UTC](https://discuss.hangfire.io/t/redis-cache-stats-entries-time-to-live/9866/2 "2023-04-28T03:09:45Z")

</div>

Hey @Anthony_Hawkley,

We had the same issue running on cloud Redis instance. We dealt with it the same way, except we used an attribute that set the expire time to 1 min. This got us around the 1 hour limitation. Keep in mind we first had set it to 24 hours. This helped bring things back down into more reasonable levels. We are running on a 250MB instance.  
 ![image](https://europe1.discourse-cdn.com/flex017/uploads/hangfire/original/2X/1/17e52f588c79804f663648cb88c1ef8f814ee2bb.png)

We left the batch jobs at default 7 days because we don’t process an unruly amount, and have seen our memory requirements be much more stable, so on a weekly bases we’re shedding around 7MB, growing 1MB.  
 ![image](https://europe1.discourse-cdn.com/flex017/uploads/hangfire/original/2X/a/abde68f13d25b3d1b78a0d84cece2cd45e73ef7d.png)

We continue to monitor it, but it’s now running at a more manageable level. We are currently pushing about 100k+ jobs a day through it.

One thing I couldn’t help but notice with your question was the size of the record you were pointing out. 80 bytes. For us that was an acceptable weight to carry for a bounded time.
