Run Release in Maintenance Mode

You can run Digital.ai Release in maintenance mode, which is a special mode for operating a single Digital.ai Release instance or an entire cluster. The primary use is to boot-up Release in maintenance mode for post-upgrade smoke testing and clean-up activities.

important

In case of a cluster, you must put all the nodes in maintenance mode. Having some nodes in maintenance mode and some in normal mode could leave the cluster unpredictable.

Functions that are Disrupted in Maintenance Mode

The following Release functions are suspended while you run Release in maintenance mode.

• Automatic triggering of tasks and releases.
• Archiving - No releases are archived while in maintenance mode. However, releases that are completed in maintenance mode are pre-archived.
• Archive Purging - Archived releases are purged once you turn off the maintenance mode.
• E-mail Notifications - No email notifications are sent to any user, regardless of the role, permissions, and so on.
• Non-Admin User Access - Log-in to Release and access to REST APIs are restricted only to administrators.
• Task Recovery - If there are tasks to recover after shutdown, the recovery happens only on the next regular start up of the Release server.

Enable Maintenance Mode in Release

Maintenance mode is enabled by configuring it in the <distribution_root>/conf/xl-release.conf file. For Operator-based setups, see Enable Maintenance Mode on Kubernetes.

Here's a list of xl-release.conf file keys that you must set to put Release in maintenance mode.

Path	Allowed values	Description
xl.maintenance.enabled	true/false	Enable or disable maintenance mode respectively
xl.maintenance.restrictApiAccess	true/false	If set to false, only administrators can access the REST API endpoints. If set to true, no one can access the REST API. All REST API invocations will result with HTTP 503 Service unavailable. Note that xl.maintenance.restrictApiAccess is evaluated only if xl.maintenance.enabled is set to true

important

Changing the maintenance mode state of the Release server requires a restart. The server must be shut down, maintenance mode enabled or disabled, and then started again.

Enable Maintenance Mode on Kubernetes

For Operator-based setups running Release version 25.3.1, or later, you can enable maintenance mode by patching the Release custom resource:

kubectl patch -n digitalai digitalaireleases.xlr.digital.ai dai-xlr \
  --type=merge --patch '{"spec":{"maintenanceMode": {"enabled": true}}}'

When you apply this patch, the operator automatically:

• Updates the xl-release.conf configuration file with the maintenance mode settings
• Modifies the Release pod health check probes
• Triggers a Release pod restart to apply the changes

To disable maintenance mode, patch the resource with enabled: false:

kubectl patch -n digitalai digitalaireleases.xlr.digital.ai dai-xlr \
  --type=merge --patch '{"spec":{"maintenanceMode": {"enabled": false}}}'

For more information on how the operator applies changes to the Release custom resource, see Update Parameters in the Custom Resource File.

What Happens to Triggers During Maintenance Mode?

When the Release server is in maintenance mode, all triggers are temporarily disabled. Triggers that would normally fire during this period are not executed.

Once maintenance mode is disabled and the server starts again, the system does not attempt to replay all missed trigger executions. Instead, the behavior depends on the trigger type.

Trigger Behavior After Maintenance Mode

The following table describes how different trigger types are handled after maintenance mode ends.

Trigger Type	Behavior After Maintenance Mode
Fixed-time trigger (for example, releases with Start automatically on selected date)	The trigger is executed once when the server starts after maintenance mode.
Simple repeating trigger (for example, Git poll every 10 seconds)	Missed executions are not retried. Triggering resumes on the next scheduled interval.
CRON-based trigger	Missed executions are not retried. Triggering resumes according to the CRON schedule.

Missed Trigger Executions

Triggers that fire repeatedly (such as polling or CRON-based triggers) do not replay all missed events after maintenance mode.

For example:

• If the server is in maintenance mode between 13:00 and 14:00
• And a Git polling trigger runs every minute
• And multiple commits occur during that hour

Only the state at the first poll after maintenance mode ends is considered. Earlier events that occurred during maintenance mode are not processed individually.

This behavior is intentional and prevents a backlog of trigger executions from overwhelming the system when it returns to normal operation.