Appian Knowledge Base

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Wed, 22 Jul 2026 20:33:23 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 7/22/2026 8:33:23 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

The license appian.lic is digitally signed using a private signing key, while the Appian Operator contains the corresponding public key used to validate those licenses. When the signing key is rotated, the Appian Operator must contain the updated public key to validate licenses signed with the new private key.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
October 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?
Do existing licenses stop working after the rotation?
Can customers upgrade the Appian Operator before requesting a new license?

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Yes. This is the recommended approach. The latest operator trusts both the previous and current signing keys, allowing it to validate both existing licenses and newly generated licenses. Older Appian Operator versions trust only the previous signing key and cannot validate licenses generated after the signing key rotation.

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Wed, 22 Jul 2026 20:32:56 GMT

Revision 10 posted to Appian Knowledge Base by pauline.delacruz on 7/22/2026 8:32:56 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
October 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?
Do existing licenses stop working after the rotation?
Can customers upgrade the Appian Operator before requesting a new license?

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 16:21:08 GMT

Revision 9 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 4:21:08 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?
Do existing licenses stop working after the rotation?
Can customers upgrade the Appian Operator before requesting a new license?

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 16:16:17 GMT

Revision 8 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 4:16:17 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 16:16:02 GMT

Revision 7 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 4:16:02 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 16:13:49 GMT

Revision 6 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 4:13:49 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 16:13:20 GMT

Revision 5 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 4:13:20 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 16:12:05 GMT

Revision 4 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 4:12:05 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

Tags: infrastructure, Kubernetes

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 16:11:11 GMT

Revision 3 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 4:11:11 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

Ryan Good — Thu, 16 Jul 2026 16:07:08 GMT

Revision 2 posted to Appian Knowledge Base by Ryan Good on 7/16/2026 4:07:08 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

KB-2390 License Signing Key Rotation for Kubernetes Native Appian

pauline.delacruz — Thu, 16 Jul 2026 15:45:20 GMT

Revision 1 posted to Appian Knowledge Base by pauline.delacruz on 7/16/2026 3:45:20 PM

Overview:

For security reasons, the Kubernetes Native Appian license signing key is rotated approximately every two years.

As a result, customers must upgrade their Appian Operator before requesting a new license generated after a signing key rotation.

Customer Impact:

Customers running old Appian Operator versions should upgrade their operator before requesting a new license after the signing key rotation. If a customer requests a new license without first upgrading the operator, the new license will fail validation with the following error for the Appian Operator:
```
Failed to verify signature #l with key …
```
Customers can safely upgrade their Appian Operator before requesting a new license, even if they are still using an existing license signed with the previous key.
If a customer has an internal change management or security processes that require validating new container images before deploying them, we recommend validating and approving the latest Appian Operator in advance. Always remember to deploy the latest operator before deploying a new appian.lic as this helps avoid delays caused by requesting a license that cannot be validated by an older operator.

Rotation Schedule:

Date	Operator Version	Details
August 2024	v0.161.0	The previous license signing key rotation occurred.
July 2026	v0.205.0	The next license signing key rotation will take place. Operator v0.205.0 introduces the new public key required to validate licenses signed after the 2026 rotation.

After the rotation: Customers requesting a newly generated license must be running Appian Operator v0.205.0 or later. Older operator versions will not recognize licenses signed with the new key.
Until the next signing key rotation: Appian Operator v0.205.0 and later will continue to validate licenses signed with the current signing key.

FAQ:

Why is the signing key rotated?

Rotating signing keys is a standard security practice that helps maintain the integrity and security of digitally signed licenses.

Do existing licenses stop working after the rotation?

No. Existing licenses continue to function as normal. The change only affects newly generated licenses signed with the new signing key.

Can customers upgrade the Appian Operator before requesting a new license?

Affected Versions

This article applies to all supported versions of Appian on Kubernetes.

Last reviewed: July 2026

KB-2389 System Process Models show up in the health check results after AI Agents are enabled

Kaushal Patel — Mon, 06 Jul 2026 14:25:23 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 7/6/2026 2:25:23 PM

Symptoms

This issue occurs after upgrading to Appian Platform version 25.4 and enabling the AI Agents feature.

The Health Check findings in either the emailed Health Check results or the Findings list in MyAppian may include:

DSGN-0013 (Process Model Alert Settings)
DSGN-0200 (Number of process models with sequential script tasks)

These findings may be reported for the following process models, which are not connected to an application:

Run Agent
Agent Execute Agentic Tool
Agent Query Record Tool
Agent Set Variable Tool
Log Agent Run

Cause

The AI Agents feature creates Appian-internal system process models used to run and manage AI Agents. These system-level process models are flagged by Health Check rules that are intended for user-created process models.

This issue has been reported to the Appian Product Team under reference LCP-39001.

Action

These system process models are not visible or editable. The associated Health Check findings can be safely ignored in MyAppian.

Instructions for ignoring specific findings are available within the MyAppian interface.

Affected Versions

Appian 25.4 and later when AI Agents are enabled.

Last Reviewed: July 2026

KB-XXXX System Process Models show up in the health check results after AI Agents are enabled

Kaushal Patel — Mon, 06 Jul 2026 14:25:07 GMT

Revision 1 posted to Appian Knowledge Base by Kaushal Patel on 7/6/2026 2:25:07 PM

Symptoms

This issue occurs after upgrading to Appian Platform version 25.4 and enabling the AI Agents feature.

The Health Check findings in either the emailed Health Check results or the Findings list in MyAppian may include:

DSGN-0013 (Process Model Alert Settings)
DSGN-0200 (Number of process models with sequential script tasks)

These findings may be reported for the following process models, which are not connected to an application:

Run Agent
Agent Execute Agentic Tool
Agent Query Record Tool
Agent Set Variable Tool
Log Agent Run

Cause

This issue has been reported to the Appian Product Team under reference LCP-39001.

Action

These system process models are not visible or editable. The associated Health Check findings can be safely ignored in MyAppian.

Instructions for ignoring specific findings are available within the MyAppian interface.

Affected Versions

Appian 25.4 and later when AI Agents are enabled.

Last Reviewed: July 2026

KB-2388 Information about the copy.fail Linux kernel security vulnerabilities (CVE-2026-31431 and CVE-2026-43284)

Kaushal Patel — Mon, 06 Jul 2026 13:56:56 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 7/6/2026 1:56:56 PM

On 29 April 2026, a critical Local Privilege Escalation (LPE) and container escape vulnerability, dubbed "copy.fail” was disclosed in the Linux kernel. This was followed by another LPE kernel vulnerability on 08 May 2026, named “Dirty Frag”.

Appian investigated these vulnerabilities and its potential impact on our infrastructure and services, and has remediated them.

Additional Notes:

The following CVEs were released with additional information on the scope of the vulnerability:

CVE-2026-31431 - (Linux Kernel Incorrect Resource Transfer Between Spheres Vulnerability)

CVE-2026-43284 - (Linux Kernel Local Privilege Escalation / Dirty Frag Page Cache Corruption)

Supporting Documentation:

Affected Versions

This article applies to all supported versions of Appian.

Last reviewed: July 7, 2026

KB-2253 2026 Holidays and On-Call Hours FAQ

Maggie Deppe-Walker — Fri, 03 Jul 2026 04:22:08 GMT

Current Revision posted to Appian Knowledge Base by Maggie Deppe-Walker on 7/3/2026 4:22:08 AM

Table of Contents:

Customer support during on-call hours and holidays

Appian Professional or Signature, legacy Advanced, Enterprise, Premier and Premier Plus customers are entitled to 24x7 support for production issues (P1 and P2 cases only). This means that these customers will be supported over the weekends and bank holidays by on-call engineers.

Below are the required steps Advanced or Enterprise, legacy Premier and Premier Plus customers must take to get support from on-call engineers:

Raise a support case
Contact support via phone

On-call hours within each region

Time zone	Hours
EST	Fri 18:00 to Sun 18:00
GMT/BST	Fri 23:00 to Sun 22:00
AEST	Sat 09:00 to Mon 08:00

Holiday dates within each region

Below is a list of all holidays in various regions for the remainder of 2025 and 2026. A number of these holidays now include blackout dates. See Blackout Periods further down this KB article for details of dates and restricted activities.

Region	Holiday	Date
USA	Thanksgiving (2 days)	Thursday 27th & Friday 28th November 2025
	Christmas (2 days)	Wednesday 24th & Thursday 25th December 2025
	New Year’s Day	Thursday 1st January 2026
	Memorial Day	Monday 25th May 2026
	Independence Day	Saturday 4th July 2026
	Labor Day	Monday 7th September 2026
	Thanksgiving (2 days)	Thursday 26th & Friday 27th November 2026
	Christmas (2 days)	Friday 25th & Saturday 26th December 2026
	New Year’s Day	Friday 1st January 2027
UK (EMEA)	Christmas (2 Days)	Thursday 25th and Friday 26th December 2025
	New Year's Day	Thursday 1st January 2026
	Good Friday	Friday 3rd April 2026
	Easter Monday	Monday 6th April 2026
	Early May UK Bank Holiday	Monday 4th May 2026
	Spring UK Bank Holiday	Monday 25th May 2026
	Summer UK Bank Holiday	Monday 31st August 2026
	Christmas (2 Days)	Friday 25th & Saturday 26th December 2026
	New Year's Day	Friday 1st January 2027
Sydney (APJ)	Labour Day	Monday 6th October 2025
	Christmas (2 Days)	Thursday 25th and Friday 26th December 2025
	New Year's Day	Thursday 1st January 2026
	Australia Day	Monday 26th January 2026
	Good Friday	Friday 3rd April 2026
	Easter Monday	Monday 6th April 2026
	Anzac Day	Saturday 25th April 2026
	King's Birthday (NSW)	Monday 8th June 2026
	Labour Day	Wednesday 7th October 2026
	Christmas (2 Days)	Wednesday 25th & Thursday 26th December 2026
	New Year's Day	Friday 1st January 2027

Blackout Periods

During Blackout Dates, only critical maintenance activities are performed.

These dates apply globally, even if the holiday only takes place in a single region:

Blackout Start Date*	Blackout End Date**
Wednesday 26th November 2025	Monday 1st December 2025
Friday 19th December 2025	Wednesday 7th January 2026
Thursday 2nd April 2026	Monday 6th April 2026
Friday 22nd May 2026	Monday 25th May 2026
Thursday 2nd July 2026	Monday 6th July 2026
Friday 4th September 2026	Tuesday 8th September 2026
Wednesday 25th November 2026	Monday 30th November 2026
Friday 18th December 2026	Monday 4th January 2027

* Maintenance Windows or Upgrades cannot be scheduled after 4:00 PM EST / EDT on the Blackout Start Date
Maintenance Windows or Upgrades can** be scheduled after 10:00 PM EST / EDT on the Blackout End Date

Tags: administration, FAQ

KB-2387 421 redirect issue caused by AWS HTTPD patching

pauline.delacruz — Tue, 30 Jun 2026 19:25:50 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 6/30/2026 7:25:50 PM

Symptoms

After upgrading Apache httpd to version 2.4.63 or later, users may see the following error when accessing their environments that use an AWS Application Load Balancer (ALB):

421 Misdirected Request: The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

Cause

A change introduced in Apache httpd 2.4.63 (and versions after) affects how the server handles SNI matching for connections routed through an AWS ALB, causing Apache to reject requests with a 421 Misdirected Request.

This is a known incompatibility between Apache httpd 2.4.63+ and AWS ALB configurations. The issue is documented in the AWS community forum: Misdirected Request with Apache 2.4.52+ behind ALB.

Action

The recommended resolution is to revert the Apache httpd upgrade to a version prior to 2.4.63.

Affected Versions

This article applies to all self-managed versions of Appian using Apache httpd 2.4.63 and later, and have ALB in their environment.

Last Reviewed: June 2026

Tags: known issues, apache, infrastructure

KB-2386 Log ingestion pipelines fail for login-audit.csv after upgrading to Appian 25.4

pauline.delacruz — Mon, 15 Jun 2026 16:05:32 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 6/15/2026 4:05:32 PM

Symptoms

After upgrading to Appian 25.4, automated log ingestion pipelines (such as Splunk, Datadog, ELK, or custom Appian expression rules) that process the <APPIAN_HOME>/logs/login-audit.csv file and rely on strict positional parsing or headerless formats may fail or parse data incorrectly.

As a result, administrators may experience a temporary loss of login audit data visibility in downstream reporting stores, or trigger internal security/IT alerts due to these ingestion job failures.

Cause

This issue is caused by schema changes introduced in Appian 25.4 to support the new "Multi-Factor Authentication: Authenticator Apps" feature.

Pipelines relying on headerless parsing or strict positional index mapping will fail due to two structural modifications:

Inclusion of Headers: Row 1 of login-audit.csv now contains column headers. Historically, this file was headerless.
New MFA Tracking Column: A new column was appended to the log to track native MFA events.
- In Appian 25.4, this column was initially introduced as MFA User.
- In Appian Hotfix 25.4.371.0, this column was renamed to MFA Authenticated and its behavior was refined to accurately distinguish genuine Appian MFA events from SSO/LDAP authentications.
- Note: true indicates successful authentication using Appian native MFA, while false indicates external authentication (SSO/LDAP), primary authentication failure, or MFA not being enabled.

Strict positional parsing of the login-audit.csv file without accounting for the newly added header row is no longer a supported ingestion approach.

For more information about login-audit.csv, refer to Logging.

Action

To resolve this issue and prevent future disruptions, log ingestion scripts and parsers must be updated:

Account for the Header Row: Update ingestion scripts to ignore the first row as data, treating it instead as the schema definition.
Update Parsing Logic: Switch from positional indexing to header-based mapping (e.g., map by the exact header string MFA Authenticated). This guarantees pipeline stability even if column orders change in future releases.

Affected Versions

This article applies to Appian 25.4 and later.

Last Reviewed: June 2026

Tags: integration, authentication

KB-1575 How to enable loggers for commonly seen Appian issues

Kaushal Patel — Thu, 04 Jun 2026 16:33:56 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 6/4/2026 4:33:56 PM

Purpose

In certain troubleshooting scenarios, it may be necessary to enable DEBUG logging to retrieve additional information related to the issue observed. This article details how to enable DEBUG logging for some of the most commonly seen issues in Appian. The DEBUG statements will be logged to the application server log, unless configured otherwise.

Instructions

Warning: Enabling the DEBUG logs in an environment can lead to large log files and introduce potential performance degradation. Appian Technical Support advises to enable loggers on lower environments before doing so on production.

The steps to enable DEBUG logging are as follows:

Open the appian_log4j.properties file. The location varies based on the version:
1. For Appian 25.4 and later, edit the config map containing the appian_log4j_override.properties file. If this is the first time the logging is being used, please follow the documentation to generate the appian_log4j_override.properties file
2. For Appian 18.3 and later, this file can be found in <APPIAN_HOME>/deployment/web.war/WEB-INF/resources.
3. For Appian 18.2 and earlier, this file can be found in <APPIAN_HOME>/ear/suite.ear/resources.
Find and uncomment the lines which apply to the particular issue you are trying to troubleshoot.
Set the value of the line to DEBUG.
Save and exit out of the file.

The steps to disable DEBUG logging are as follows:

Return to the appian_log4j.properties file, and update the lines you modified so that the value is changed from DEBUG back to ERROR.
Save the file and check the application server log to verify that the DEBUG and TRACE log entries are no longer being recorded.

When adding any of these loggers, check if they already exist in appian_log4j.properties, if they do, edit the existing line, otherwise add the lines to the appian_log4j.properties.

Loggers:

Appian Authentication, SAML, LDAP:

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.core.xml.util=TRACE

OpenID Connect User Authentication:

log4j.logger.com.appiancorp.security.auth.oidc=DEBUG

OAuth 2.0 Token Request Sequence:

log4j.logger.com.appiancorp.connectedsystems.http.oauth.HttpOAuthTokenRetriever=DEBUG
log4j.logger.com.appiancorp.connectedsystems.contracts.HttpOAuthTokenService=DEBUG
log4j.logger.com.appiancorp.connectedsystems.http.execution.strategies=DEBUG
log4j.logger.com.appiancorp.connectedsystems.http.oauth=DEBUG
log4j.logger.com.appiancorp.oauth.inbound=DEBUG

Application Import/Export:

log4j.logger.com.appiancorp.ix=DEBUG

Appian Health Check:

Note: Only applicable when using the Health Check Plugin. These loggers do not apply when Health Check is configured through the Admin Console.

log4j.logger.com.appiancorp.plugins.labs.BulkLogDownloadServlet=DEBUG
log4j.logger.com.appiancorp.tools.labs.analysis.util.LabsFileFilter=DEBUG
log4j.logger.com.appiancorp.healthcheck=DEBUG, HEALTH_CHECK

CDT Import/Export:

log4j.logger.com.appiancorp.type.external.teneoimpl.TeneoAnnotationsValidator=DEBUG
log4j.logger.com.appiancorp.type.external.teneoimpl.AppianHbSessionDataStore=DEBUG

Starting Processes by E-mail (email polling):

log4j.logger.com.appiancorp.messaging.MessagePublisherServiceImpl=DEBUG 
log4j.logger.com.appiancorp.process.execution.service.ProcessExecutionServiceFacade=DEBUG 
log4j.logger.com.appiancorp.mdb=DEBUG

Process Models Exposed as Web Services:

log4j.logger.com.appiancorp.process.webservices.pmserver=DEBUG

Process to Process Messaging:

log4j.logger.com.appiancorp.messaging.MessagePublisherServiceImpl=DEBUG 
log4j.logger.com.appiancorp.process.execution.service.ProcessExecutionServiceFacade=DEBUG

Query Timeouts:

log4j.logger.org.hibernate.util.JDBCExceptionReporter=DEBUG

Query RDBMS Execution and Validation:

log4j.logger.com.appiancorp.process.runtime.activities.QueryRdbmsActivity=DEBUG
log4j.logger.com.appiancorp.process.runtime.activities.JdbcActivity=DEBUG

Capture SQL Statements:

log4j.logger.org.hibernate.SQL=DEBUG
log4j.logger.org.hibernate.type=TRACE

SAIL (unmask pink pop-up errors):

log4j.logger.com.appiancorp.rest.shared.AppianExceptionMapper=DEBUG
log4j.logger.com.appiancorp.core.expr.tree.Variable=DEBUG
log4j.logger.com.appiancorp.core.expr.Parse=DEBUG

Sending Emails with Send Email Smart Service:

log4j.logger.com.appiancorp.process.runtime.activities.SendEmailActivity=DEBUG
log4j.logger.com.appiancorp.ap2.mail=DEBUG

Call Web Service Smart Service:

log4j.logger.com.appiancorp.ws=DEBUG
log4j.logger.org.apache.axis2=DEBUG
log4j.logger.httpclient.wire.header=TRACE
log4j.logger.org.apache.commons.httpclient=TRACE

Importing Web Service CDTs:

log4j.logger.com.appiancorp.type.config.xsd.SchemaFactory=DEBUG

Background activity in Appian Engines:

log4j.logger.com.appiancorp.process.background.EngineWorkSpringContextListener=DEBUG
log4j.logger.com.appiancorp.process.background.EngineWorkControllerFactory=DEBUG
log4j.logger.com.appiancorp.process.background.EngineWorkControllerRunnable=DEBUG
log4j.logger.com.appiancorp.process.background.EngineWorkController=DEBUG

Details on CDT Transformation:

log4j.logger.com.appiancorp.type.xmlconversion=DEBUG 
log4j.logger.com.appiancorp.suiteapi.common.TypeConverter=DEBUG 
log4j.logger.com.appiancorp.core.data.converter=DEBUG

High Transformation Time When Processing the Results Received from the RDBMS:

log4j.logger.com.appian.perflogs.ecore-tv-conversion-trace=INFO, ECORE_TV_CONVERSION_PERF_TRACE
log4j.additivity.com.appian.perflogs.ecore-tv-conversion-trace=false
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE=com.appiancorp.common.logging.AppianFileAppender
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.layout=com.appiancorp.type.data.ecore.EcoreToTvConversionPerfLogger$TraceLayout
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.File=${AE_LOGS}/perflogs/perf_ecore_tv_conversion_trace.csv
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.MaxFileSize=10MB
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.MaxBackupIndex=1000
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.encoding=UTF-8

Workpoller Issues:

log4j.logger.com.appiancorp.ra.workpoller=DEBUG, WORK_POLLER

Plugin Deployment:

log4j.logger.com.appiancorp.process.admin=DEBUG

XSD Validation:

Note: This is used when record type validation fails or when deploying a plugin which constructs a CDT.

log4j.logger.com.appiancorp.type.config.xsd=DEBUG

HTTP Connected Systems Request Execution:

Note: This is to check the request contents, how it was received, if response was received or timed out, etc.

log4j.logger.com.appiancorp.connectedsystems.http=DEBUG
log4j.logger.com.appiancorp.connectedsystems.http.execution.AppianHttpRequestExecutor=DEBUG

Connected Environments DevOps:

log4j.logger.com.appiancorp.connectedenvironments.logging.DevOpsInfrastructureHandlerAuditLogger=DEBUG
log4j.logger.com.appiancorp.designobjectdiffs.functions.application.DodConnEnvCallSystemRuleHandler=DEBUG

Connected Environment (Retrieval of Public Keys):

log4j.logger.com.appiancorp.connectedenvironments.ConnectedEnvironmentPublicKeyRetriever=DEBUG
log4j.logger.com.appiancorp.connectedenvironments.service.ConnectedEnvironmentsInitialRequestor=DEBUG
log4j.logger.com.appiancorp.connectedenvironments.service.JwtUtils=DEBUG
log4j.logger.com.appiancorp.connectedenvironments.KeyUtils=DEBUG

Compare & Deploy (Inspection phase): Compare

log4j.logger.com.appiancorp.designdeployments.handler.DplConnEnvAsyncInspectHandler=DEBUG
log4j.logger.com.appiancorp.designdeployments.handler.DplConnEnvInspectHandler=DEBUG

Salesforce connected Systems (returns error stacktrace returned by Salesforce):

log4j.logger.com.appiancorp.connectedsystems.salesforce=DEBUG

Webserver (returns data transferred to and from the servers when executing HTTP requests): Quick Apps:

**these loggers are verbose, switch loggers to ERROR first before removing them from appian_log4j.properties file

log4j.logger.org.apache.http=DEBUG
log4j.logger.org.apache.http.wire=DEBUG

Quick Apps:

log4j.logger.com.appiancorp..object.quickapps.QuickAppObjectType=TRACE

Deployment Stuck in Progress:

log4j.logger.com.appian.kafka.KafkaTopicManager=DEBUG

Record Sync Incidents:

log4j.logger.com.appiancorp..record.data.recordloaders.ads.AdsReplicaTransaction=DEBUG
log4j.logger.com.appiancorp.record.fn.RefreshReplicaForRecordTypeReaction=DEBUG
log4j.logger.com.appiancorp.record.service.RecordReplicaUpdateService=DEBUG
log4j.logger.com.appiancorp.record.service.quartz.ReplicaLoadJob=DEBUG
log4j.logger.com.appiancorp.record.replicaupdate.LogRyowVsBulk=DEBUG
log4j.logger.com.appiancorp.record.service.ReplicaSyncPollerImpl=DEBUG
log4j.logger.com.appiancorp.record.service.quartz.scheduling.ScheduleManagerImpl=DEBUG
log4j.logger.com.appiancorp.record.service.quartz.LoggingTriggerListener=DEBUG

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: June 2026

Tags: logging, administration, application server, how-to

[DRAFT SUPP-1739] 421 redirect issue caused by AWS HTTPD patching

kaitlyn.wee — Wed, 03 Jun 2026 20:05:55 GMT

Revision 7 posted to Appian Knowledge Base by kaitlyn.wee on 6/3/2026 8:05:55 PM

Symptoms

After upgrading Apache httpd to version 2.4.63 or later, users may see the following error when accessing their environments that use an AWS Application Load Balancer (ALB):

421 Misdirected Request: The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

Cause

This is a known incompatibility between Apache httpd 2.4.63+ and AWS ALB configurations. The issue is documented in the AWS community forum: Misdirected Request with Apache 2.4.52+ behind ALB.

Action

The recommended resolution is to revert the Apache httpd upgrade to a version prior to 2.4.63.

Affected Versions

This article applies to all self-managed versions of Appian using Apache httpd 2.4.63 and later, and have ALB in their environment.

Last Reviewed: June 2026

Tags: known issues, apache, infrastructure

[DRAFT SUPP-1739] 421 redirect issue caused by AWS HTTPD patching

kaitlyn.wee — Wed, 03 Jun 2026 20:05:16 GMT

Revision 6 posted to Appian Knowledge Base by kaitlyn.wee on 6/3/2026 8:05:16 PM

Symptoms

After upgrading Apache httpd to version 2.4.63 or later, users may see the following error when accessing their environments that use an AWS Application Load Balancer (ALB):

421 Misdirected Request :The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

Cause

This is a known incompatibility between Apache httpd 2.4.63+ and AWS ALB configurations. The issue is documented in the AWS community forum: Misdirected Request with Apache 2.4.52+ behind ALB.

Action

The recommended resolution is to revert the Apache httpd upgrade to a version prior to 2.4.63.

Affected Versions

This article applies to all self-managed versions of Appian using Apache httpd 2.4.63 and later, and have ALB in their environment.

Last Reviewed: June 2026

Tags: known issues, apache, infrastructure