Run history workflow timing values questionable

Question

Run history workflow timing values questionable

Christopher Fryett 125

I have the following high-level scenario:

Main workflow

Trigger occurs and variables initialized
do-while loop boolean - break on true
1. check if loop variable = false, if false - continue
2. sql connector - get row
3. if get row returns 404 call another workflow for deeper search
  1. in workflow calls another workflow for authentication tokens
    1. calls 2 function apps for different types of tokens (to complex for logic apps), returns token
  2. in workflow use http connector - issues call to 3rd party api with tokens
  3. return response from http
4. if workflow returns 404, insert info to db and set loop break to true
return results

Happy path there would only be 1 iteration hitting 'b' and onward.

When I look at the run history and the times each action takes it does not reflect the actual times in the subflows. This gives some misleading or skewed timings on how long a primary/main flow actually runs, or is the timings accurate and each call to a subflow could take 2 or more seconds? For example, the main flow says it takes 6 second for 'c' to complete but when looking at that run history it shows it took 4.3 s. And that flow calls 'i' and says it completed in 2s but the calling flow 'ii' took 0.8s. Overall, the mainflow takes 10s to complete whereas if I wrote a C# app it likely will be a fraction of that. The get and insert rows are fast in the main flow. Hopefully I didn't make this confusing.

In order to reduce making workflows large I have broken them down for reuse and also readability per se.

I am running logic apps and function apps under the app service plan IVI2.

Answer accepted by question author

0 additional answers

Your answer

Answer 1

the thing is, the timings you see in the logic app run history include overhead that you wouldn't have in a pure c# app. every time you call a nested workflow or a function app, there's a bit of orchestration latency. azure has to spin up the action, validate permissions, and handle the communication between services. that can easily add a second or two per call.

so when your main flow shows 6 seconds for step 'c', but the sub-flow itself only took 4.3 seconds, that extra 1.7 seconds is likely the overhead of starting and stopping that child workflow. same thing with your function apps. the http connector itself might report 0.8 seconds, but the function app's cold start time and execution time are bundled into that.

this might help in other scenarios too, always expect some overhead with distributed systems.

if you want to get a more accurate picture, add some logging at the very start and very end of your function apps. log the exact datetime when the function begins and ends. compare that to the timings in the logic app. you'll probably see that the function itself is fast, but the trigger and response steps add time.

also, check the scale settings on your app service plan. if you're on a lower tier, cold starts can be more pronounced. moving to a premium plan might shave off some time, but it won't eliminate the orchestration overhead completely.

unfortunately, that's just the nature of a low code platform like logic apps. you trade off raw performance for development speed and ease of use. for most business processes, a 10 second total run time is acceptable, but if you need millisecond performance, a custom c# app running on a dedicated app service would be the way to go.

hope this clarifies things. those timings are probably "accurate" from azure's perspective, even if they include overhead you wouldn't expect. let me know if you want to dive deeper into optimizing specific steps.

Best regards,

Alex

and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer

https://ctrlaltdel.blog/

Francesco Colombo 0 Reputation points

2025-10-20T13:42:31.2866667+00:00

@Alex Burlachenko while looking for an answer to a similar question I had I found your answer here, which makes totally sense to me but, what would be the explanation for situations like this?

On this run, the loop iterated 5 times, with an average time of 30s per iteration.

Why the total time is 8m?
Alex Burlachenko 18,310 Reputation points Volunteer Moderator

2025-10-20T14:17:13.31+00:00

you have perfectly identified a key behavior of logic apps that is not obvious at all.

what you are seeing is not the sum of the loop's execution time, but the total elapsed time from when the loop started until it finished. this is the crucial difference.

imagine your loop runs 5 iterations, each taking 30 seconds of active work. in a perfect world, that would be 2.5 minutes total. but logic apps does not run loop iterations back to back like a c# for loop would.

there is a built in delay or 'buffer' between each iteration of the loop. the logic apps engine does not immediately start the next iteration as soon as the previous one finishes. it pauses for a bit. this is a design feature to prevent the engine from being overwhelmed and to handle potential throttling from connectors.

so, if each iteration takes 30 seconds of active work, but the engine waits for, let's say, 1.5 minutes before starting the next one, your timeline would look like this.

iteration 1. 0s to 30s pause. 30s to 2m 0s iteration 2. 2m 0s to 2m 30s pause. 2m 30s to 4m 0s iteration 3. 4m 0s to 4m 30s and so on.

by the time the 5th iteration finishes, the total elapsed time could easily be around 8 minutes, even though the active work was only 2.5 minutes. the rest of the time was the engine waiting between cycles.

this behavior is especially pronounced when using http connectors or any action that might be subject to rate limiting. the engine is being cautious.

so, to summarize. the 8 minute total is the real clock time from start to finish. the 30 second average is the active processing time per iteration. the difference is the built in pacing that the logic apps engine applies between loop cycles.

rgds,

Alex

Share via

Run history workflow timing values questionable

0 additional answers

Your answer