
Highlight
What is retry policy in logic apps, and why it costs?
Intro
Retry policies is something that everyone working in the cloud should be aware of. The idea is fairly simple, if you fail to execute an action, try again a few more times.
Typically retry policies have two parameters that you set
- Retries - how many times is a particular action going to be retried
- Retry Interval - and how much time should pass between each individual retry, there are two settings for it
- Increasing Inteval - This means how much more time between each execution should pass, sometimes it’s exponential, sometimes it’s a flat addition, but generally it can go like (X*X seconds) 2s, 4s, 8s, 16s, etc. or flat calculation like (X + 2 seconds) 2s, 4s, 6s, 10s, etc.
- Static Interval - Or simply set to always try every X seconds, like 2s, 2s, 2s, 2s, etc.

Why should I care?
Again, great question. You should you care? Well, mostly because of two things
- Every retry will extend the duration of your logic app workflow runs
- Every retry will cost you - yes, you’ve heard it, retries are not free, you will pay for every action. Although it should be noted that this is only the case for consumption logic apps, or azure connectors in logic app standard.
And the point 2 is the important one, although 1 also has implications on it’s own.
So, why exactly is this important besides the obvious points? All Logic Apps connectors always have retry policies set to 4. So if you just leave the default, and your logic app will start failing, then all your logic aps will try 4 times each action before finally failing. This might overload your end APIs or create huge cost for your logic apps if you leverage consumption tier.

Summary
Retries are a good thing, and you most likely should leave this as default in like 90% of cases. But being aware of this setting, might help tremendously with those 10% of cases where you should be changing this parameter.