Flex Consumption is a hosting plan for Azure Functions that combines serverless, pay-for-what-you-use billing with more control over how your app runs. It gives you fast, elastic scaling, the choice of instance size, private networking, availability zones, and always-ready instances to cut down cold starts. In short, it’s built for teams who want the simplicity of serverless but need more flexibility than the classic Consumption plan offers. Personally speaking, it’s my default plan for quite all the Azure Function App I create today for production workloads.
Azure Functions on the Flex Consumption plan can now deploy with zero downtime. This works through a new feature called rolling updates, that was recently silently moved as generally available (GA).
Before this feature, every deploy on Flex Consumption worked the same way as in the other plans: the platform restarted all running instances at once. Any code running at that moment was cut off. The app also had a short period of downtime while new instances started up from scratch.
How rolling updates work?
Instead of restarting everything at once, with this feature active the platform now replaces instances gradually. It drains small batches of instances every few seconds, and scales out new instances running the updated version to keep up with demand. If you have instances that are already running they are not forced to stop and they will finish the task.
Activating this feature work your Flex Consumption app is very easy. Just go to your function app in the Azure Portal, select Settings | Configuration and on the Platform settings set Site update strategy to Rolling update (default is Recreate, that forcefullt termitaes instances before scaling-out new ones, resulting in a brief downtime):
You can also activate this feature by using Azure CLI:
az functionapp update-strategy config set --name MyFunctionApp --resource-group MyResourceGroup --type RollingUpdate
There’s no automatic rollback. If something goes wrong, you can fix it by just deploying your last known-good version again. Your changes need also to be backward compatible. Unlike the Recreate strategy, where only one version ever runs at a time, a rolling update can have old and new instances running together for a short while. This matters most for stateful workloads like Durable Functions.
Rolling updates make sense when you have long-running or critical functions that can’t afford to be interrupted, and your changes don’t break backward compatibility. If you need fast deploys, you’re making breaking changes, or your functions are stateless and fine with interruptions, the simpler Recreate strategy is still a good choice.
What about Consumption and Premium plans?
Rolling updates only exist on Flex Consumption. On Consumption and Premium, a plain deploy works the same way it always has: the package is synced to running instances and they restart, with no zero-downtime guarantee.
The closest thing you get on those plans is deployment slots, but that’s something you have to set up yourself (it’s not the default behavior):
| Plan | Zero downtime by default? | How to get closer to it |
|---|---|---|
| Consumption | No | Deployment slots (1 staging slot) |
| Premium | No | Deployment slots (2 staging slots) |
| Dedicated (App Service) | No | Deployment slots (1–20 slots) |
| Flex Consumption | No (default is Recreate) | Rolling update strategy |
And even with slots, the guarantee is weaker than what rolling updates offer. Traffic routing during a slot swap is seamless (no requests are dropped). But Microsoft is clear that slot swaps don’t guarantee zero downtime: functions that are running at the moment of the swap can still be terminated, and apps under load can see reduced availability during the swap.
So the real difference is this: slots mainly smooth out traffic routing, while Flex Consumption’s rolling update actually lets in-progress executions finish.
If you need true continuity for long-running or critical functions, rolling updates on Flex Consumption is the only option that delivers it today.
Stefano Demiliani 