# Different retry algorithm for activities

**URL:** <https://community.temporal.io/t/different-retry-algorithm-for-activities/3765>\
**Category:** Community Support\
**Tags:** retries\
**Created:** [January 16, 2022, 6:47pm UTC](https://community.temporal.io/t/different-retry-algorithm-for-activities/3765 "2022-01-16T18:47:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![nitesh237](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/nitesh237/32/1656_2.png) [@nitesh237](https://community.temporal.io/u/nitesh237)\
**Post date:** [January 16, 2022, 6:47pm UTC](https://community.temporal.io/t/different-retry-algorithm-for-activities/3765/1 "2022-01-16T18:47:04Z")

</div>

I have been going through the temporal go developers guide.  
One thing I noticed in the “Activity and Workflow Retries” [section](https://docs.temporal.io/docs/go/retries/) is that temporal currently supports exponential backoff retry policy.  
However, for our use cases, we wanted to explore options on how to add custom retry policies that suites our business requirement.  
e.g. one of the policies could be a hybrid policy where the first few attempts are at regular intervals (a little more aggressive) and switch to exponential backoff after a threshold, to avoid overwhelming the systems involved.

1. I would want to understand if there is any way to enforce this in temporal workflow currently?
2. Is there any plan for extending retry policies to more algorithms than what we have currently say exponential backoff with jitter, random interval, etc. ?

---

<div class="post-metadata">

**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\
**Post date:** [January 16, 2022, 7:36pm UTC](https://community.temporal.io/t/different-retry-algorithm-for-activities/3765/2 "2022-01-16T19:36:05Z")

</div>

I would model this as two activity invocations. The first with the aggressive retry options and the second (invoked only if the first one fails) with the exponential ones.

You can wrap this pattern in a reusable piece of code.

---

<div class="post-metadata">

**Author:** ![nitesh237](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/nitesh237/32/1656_2.png) [@nitesh237](https://community.temporal.io/u/nitesh237)\
**Post date:** [January 17, 2022, 9:50am UTC](https://community.temporal.io/t/different-retry-algorithm-for-activities/3765/3 "2022-01-17T09:50:11Z")

</div>

Thanks for the quick response. Are there any future plans to provide support for different retry policies?

> [@nitesh237](#):
>
> Is there any plan for extending retry policies to more algorithms than what we have currently say exponential backoff with jitter, random interval, etc. ?

---

<div class="post-metadata">

**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\
**Post date:** [January 17, 2022, 7:19pm UTC](https://community.temporal.io/t/different-retry-algorithm-for-activities/3765/4 "2022-01-17T19:19:25Z")

</div>

Temporal activities are invoked through a task queue. Each worker allows specifying limits like a number of parallel activities and maximum activity execution rates. These are much better mechanisms “to avoid overwhelming the systems involved” than retry options.