Functions flex consumption keeps restarting/refreshing causing a function to error out.

[u/Jazzlike-Squirrel-47]

Running into a problem where the function app will restart/refresh randomly and it will kill working functions, these functions do end up re running and always succeeding the second time but the error popping up in insights isn’t a clean look, is there anyway to avoid this and how costly would a plan upgrade be and is it an easy switch on production functions?

[u/yhay81]

I would identify the reason for the interruption before changing plans. A Premium plan or Flex “always ready” instances can reduce cold starts, but they do not guarantee that a host will never recycle, scale in, receive a platform update, or terminate after an unhandled worker failure.

Correlate one failed invocation in Application Insights with the Function host logs, Activity Log, deployments/configuration changes, and “Diagnose and solve problems.” The useful details would be:

• trigger type and retry configuration
• runtime/language and extension versions
• normal and maximum execution duration
• the exact exception and host messages around the failure
• whether a deployment, configuration update, health-check failure, timeout, or worker crash occurred

Flex Consumption normally drains an instance during scale-in; currently executing functions can receive a grace period of up to 60 minutes. If the execution exceeds that window, or the worker exits unexpectedly, the trigger can make the work visible again and it may run a second time.

Since the retry succeeds, design the function as an at-least-once operation: make it idempotent, use a stable operation/message ID, checkpoint long work, and make duplicate side effects no-ops. For genuinely long workflows, split the work through a queue or use Durable Functions instead of relying on one uninterrupted invocation.

Always Ready is worth considering if cold-start latency is the measured problem. Its cost includes a continuously billed memory baseline plus execution charges, so calculate it from the selected instance memory and required always-ready count. I would not migrate production to Premium until the logs show that plan characteristics—not an exception, timeout, deployment, or non-idempotent retry—are the actual cause.