---
name: cloud-logs-agent-helm-configure-maxunavailable
title: Configuring the maximum number of unavailable pods during an update
description: When you deploy or upgrade the Logging agent, you can configure the `logs-values.yaml` file to include an optional parameter to specify how many pods can be unavailable during a rolling update.
last-updated: 2025-09-15
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/cloud-logs?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Configuring the maximum number of unavailable pods during an update
{: #agent-helm-configure-maxunavailable}

When you deploy or upgrade the Logging agent, you can configure the `logs-values.yaml` file to include an optional parameter to specify how many pods can be unavailable during a rolling update.
{: shortdesc}


The optional parameter `updateStrategy.maxUnavailable` lets you specify the maximum number or percentage of unavailable pods when the agent daemonset does a rolling update. Enclose a percentage value in quotation marks so it is interpreted as a string. Do not include a number in quotation marks so it is interpreted as int32. By default, a percentage value of `"25%"` is used. Configure the Logging agent to use a custom value by adding the `updateStrategy.maxUnavailable` configuration to your `log-values.yaml` file:

The following specifies that a maximum of 10% of pods can be unavailable.

```yaml
updateStrategy:
  maxUnavailable: "10%" # optional (default is 25%)
```
{: codeblock}

The following specifies that a maximum of 5 of pods can be unavailable.

```yaml
updateStrategy:
  maxUnavailable: 5 # optional (default is 25%)
```
{: codeblock}

After you modify the `logs-values.yaml`, you can [Upgrade the agent](https://cloud.ibm.com/docs/cloud-logs?topic=cloud-logs-agent-helm-update&format=markdown) or continue modifying the file before applying all the changes.

When the pods are updated from an old Logging agent version to a new agent version, Kubernetes will stop no more than the `updateStrategy.maxUnavailable` number of pods running the old agent version. 

When the `updateStrategy.maxUnavailable` number of old pods is reached, the rolling update will be paused until new pods with the new version are running. 

The helm command can be configured to wait for a specific time for the update to complete (see the `timeout` and `wait` [helm upgrade options](https://helm.sh/docs/helm/helm_upgrade/){: external}), but will otherwise only update the daemonset definition and let Kubernetes update the agent pods. The Kubernetes controller will keep retrying to update the agent pods indefinitely until all pods are updated.
 
If new pods are having issues coming up, the update won't continue. For more information on agent configuration errors, see [I am getting an error when starting the Logging agent?](https://cloud.ibm.com/docs/cloud-logs?topic=cloud-logs-ts-fb-error&format=markdown). Check and correct your configuration if required and retry the update.