How to set CooldownPeriod for New-AzContainerAppScaleRuleObject via Powershell CLI

Question

How to set CooldownPeriod for New-AzContainerAppScaleRuleObject via Powershell CLI

Brian Bento 0

I am setting up a new AppScaleRule for my container app but there is no documentation on how to set the cooldown period at all.

Here is part of script:

$scaleRule = New-AzContainerAppScaleRuleObject -Name "http-scaling-rule" -CustomType "http" -CustomMetadata @{"concurrentRequests"="1"}

$containerApp = @{

	ResourceGroupName = $resourceGroupName 

	SubscriptionId = $subscriptionId 

	Name = $service 

	Location = "centralus" 

	TemplateContainer = @($template)

	ManagedEnvironmentId = $managedEnvId		

	Configuration = $appConfig

	ScaleMinReplica = 0

	ScaleMaxReplica = 1

	ScaleRule = @($scaleRule)

}

New-AzContainerApp @containerApp

I have checked everywhere and there is no documentation on it - I assumed it would be at the same level as the ScaleMinReplica and ScaleMaxReplica because that is how it shows up in the UI but it doesn't exist on that in the documentation.

Tejaswini Billakurthi 670 Reputation points Microsoft External Staff Moderator

2026-09-16T11:39:47.81+00:00
Hi @Brian Bento ,

Thank you reaching out to Microsoft Q & A !

CooldownPeriod is not a property of New-AzContainerAppScaleRuleObject. That cmdlet creates an individual scaling rule, whereas the cooldown period is part of the overall Container App scale configuration.

The underlying Container Apps resource model defines cooldownPeriod at the same scale level as minReplicas, maxReplicas, pollingInterval, and rules. Microsoft documents the default cooldown period as 300 seconds when it isn't specified.

Therefore, you should not add cooldownPeriod to CustomMetadata, because that metadata belongs to the individual scaler.

One point to note is that the cooldown period applies when scaling in from the final replica to zero. It does not affect the removal of other replicas. This is particularly relevant in your configuration because you have ScaleMinReplica = 0.

If the Az.ContainerApp PowerShell cmdlet/version you're using doesn't expose the scale-level cooldown property, you can configure it through a deployment method that exposes the underlying Container Apps scale model, such as ARM/Bicep.

References:

New-AzContainerAppScaleRuleObject

Scaling in Azure Container Apps

Microsoft.App/containerApps ARM/Bicep resource reference

Hope this clarifies the distinction between the scale rule and the scale-level cooldown configuration.

Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.
Brian Bento 0 Reputation points

2026-09-16T12:46:32.93+00:00

Understood - I see how how the model works. Is there a reason these two properties aren't exposed? It seems more like an oversight than anything else.
Allan Solomon Mejia 9,485 Reputation points

2026-09-16T19:29:40.4433333+00:00

Hello @Brian Bento

Yes, I think your observation is valid. This appears to be a gap in the current Az.App PowerShell cmdlet surface, rather than a limitation of Azure Container Apps itself.

cooldownPeriod defaults to 300 seconds and pollingInterval defaults to 30 seconds when they aren't specified.

However, New-AzContainerAppScaleRuleObject only creates a ScaleRule object. Its documented parameters cover the rule name, type, metadata, and authentication, but not cooldownPeriod or pollingInterval.

So those properties wouldn't belong on $scaleRule anyway. They belong on the parent scale object. The problem is that the current Az.App PowerShell abstraction doesn't appear to expose them through the New-AzContainerApp parameters you're using.

This also explains why the Portal/API can support settings that aren't necessarily available through every PowerShell cmdlet yet.

So I agree this looks more like the Az.App PowerShell model hasn't caught up with the current Container Apps resource schema than something intentionally omitted from Container Apps.

If you specifically need non-default values today, use a current ARM/Bicep/API-based deployment rather than trying to put them into New-AzContainerAppScaleRuleObject.

Container Apps ARM/Bicep resource reference

It would also be reasonable to raise this as an Az PowerShell documentation/feature issue, because having minReplicas and maxReplicas exposed while the other two scale-level properties aren't is understandably confusing.

Please let me know if you need any further assistance. Otherwise, if the information provided helped/resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.

1 answer

Your answer

Tejaswini Billakurthi 670 Reputation points Microsoft External Staff Moderator

2026-09-16T11:39:47.81+00:00

Hi @Brian Bento ,

Thank you reaching out to Microsoft Q & A !

CooldownPeriod is not a property of New-AzContainerAppScaleRuleObject. That cmdlet creates an individual scaling rule, whereas the cooldown period is part of the overall Container App scale configuration.

The underlying Container Apps resource model defines cooldownPeriod at the same scale level as minReplicas, maxReplicas, pollingInterval, and rules. Microsoft documents the default cooldown period as 300 seconds when it isn't specified.

Therefore, you should not add cooldownPeriod to CustomMetadata, because that metadata belongs to the individual scaler.

One point to note is that the cooldown period applies when scaling in from the final replica to zero. It does not affect the removal of other replicas. This is particularly relevant in your configuration because you have ScaleMinReplica = 0.

If the Az.ContainerApp PowerShell cmdlet/version you're using doesn't expose the scale-level cooldown property, you can configure it through a deployment method that exposes the underlying Container Apps scale model, such as ARM/Bicep.

References:

New-AzContainerAppScaleRuleObject

Scaling in Azure Container Apps

Microsoft.App/containerApps ARM/Bicep resource reference

Hope this clarifies the distinction between the scale rule and the scale-level cooldown configuration.

Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.
Brian Bento 0 Reputation points

2026-09-16T12:46:32.93+00:00

Understood - I see how how the model works. Is there a reason these two properties aren't exposed? It seems more like an oversight than anything else.
Allan Solomon Mejia 9,485 Reputation points

2026-09-16T19:29:40.4433333+00:00

Hello @Brian Bento

Yes, I think your observation is valid. This appears to be a gap in the current Az.App PowerShell cmdlet surface, rather than a limitation of Azure Container Apps itself.

cooldownPeriod defaults to 300 seconds and pollingInterval defaults to 30 seconds when they aren't specified.

However, New-AzContainerAppScaleRuleObject only creates a ScaleRule object. Its documented parameters cover the rule name, type, metadata, and authentication, but not cooldownPeriod or pollingInterval.

So those properties wouldn't belong on $scaleRule anyway. They belong on the parent scale object. The problem is that the current Az.App PowerShell abstraction doesn't appear to expose them through the New-AzContainerApp parameters you're using.

This also explains why the Portal/API can support settings that aren't necessarily available through every PowerShell cmdlet yet.

So I agree this looks more like the Az.App PowerShell model hasn't caught up with the current Container Apps resource schema than something intentionally omitted from Container Apps.

If you specifically need non-default values today, use a current ARM/Bicep/API-based deployment rather than trying to put them into New-AzContainerAppScaleRuleObject.

Container Apps ARM/Bicep resource reference

It would also be reasonable to raise this as an Az PowerShell documentation/feature issue, because having minReplicas and maxReplicas exposed while the other two scale-level properties aren't is understandably confusing.

Please let me know if you need any further assistance. Otherwise, if the information provided helped/resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.

Answer 1

Hello @Brian Bento

You're looking in the right general area, but cooldownPeriod isn't actually a property of New AzContainerAppScaleRuleObject.

In the Azure Container Apps resource model, the structure is:

User's image

So cooldownPeriod applies to the Container App scaling configuration, not to an individual scaling rule. Microsoft currently documents it as an optional integer in seconds, with a default of 300 seconds when it isn't specified.

That's why you don't see a -CooldownPeriod parameter on:

New-AzContainerAppScaleRuleObject

Your $scaleRule construction is therefore only defining the rule itself:

$scaleRule = New-AzContainerAppScaleRuleObject `
    -Name "http-scaling-rule" `
    -CustomType "http" `
    -CustomMetadata @{"concurrentRequests"="1"}

The problem is that the current New-AzContainerApp PowerShell parameter set you're using exposes things such as ScaleMinReplica, ScaleMaxReplica, and ScaleRule, but doesn't expose the complete underlying template.scale model, including cooldownPeriod.

The ARM resource schema does expose it:

"template": {
  "scale": {
    "minReplicas": 0,
    "maxReplicas": 1,
    "cooldownPeriod": 60,
    "rules": [
      ...
    ]
  }
}

Microsoft documents that schema here:

Microsoft.App/containerApps ARM/Bicep reference

So if the Az PowerShell cmdlet/version you're using doesn't expose ScaleCooldownPeriod, don't put it in CustomMetadata. That metadata belongs to the scaler itself and isn't where Container Apps expects the KEDA cooldown setting.

Instead, use the ARM/Bicep representation (or another deployment method that exposes the complete template.scale object) and set: properties.template.scale.cooldownPeriod

For example, in Bicep:

template: {
  scale: {
    minReplicas: 0
    maxReplicas: 1
    cooldownPeriod: 60
    rules: [
      // scaling rule
    ]
  }
}

There is also a pollingInterval property at the same level if you need to control how frequently KEDA evaluates non-HTTP event sources; its documented default is 30 seconds.

So your assumption from the portal was correct: Cooldown Period belongs at the same logical scale level as Min Replicas and Max Replicas, not inside New-AzContainerAppScaleRuleObject. The confusing part is simply that the Az.ContainerApp PowerShell cmdlet doesn't necessarily expose every property available in the current Container Apps ARM schema.

If PowerShell is mandatory for your deployment pipeline, you can still deploy/update the ARM resource from PowerShell rather than relying exclusively on New-AzContainerApp's flattened parameters.

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.