---
title: Configuring audit log failure settings
description: The Audit Log Settings tab allows you to configure how PingFederate responds if writing to the audit log fails.
component: pingfederate
version: 13.0
page_id: pingfederate:administrators_reference_guide:pf_configuring_audit_log_failure_settings
canonical_url: https://docs.pingidentity.com/pingfederate/13.0/administrators_reference_guide/pf_configuring_audit_log_failure_settings.html
section_ids:
  steps: Steps
---

# Configuring audit log failure settings

The **Audit Log Settings** tab allows you to configure how PingFederate responds if writing to the audit log fails.

Logging can fail for a variety of reasons, including too many concurrent transactions, insufficient memory for logging, and having too many files open when trying to roll log files.

|   |                                                                                                                                                                                                                                                                                                                               |
| - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | You can prevent some of these issues by configuring a `maxRandomDelay` attribute to the `TimeBasedTriggeringPolicy` parameter in the `log4j2.xml` file. Learn more in [Rolling File Appenders](https://logging.apache.org/log4j/2.x/manual/appenders/rolling-file.html#TimeBasedTriggeringPolicy) in the Log4J documentation. |

By default, PingFederate fails transactions when logging fails, which can prevent users from accessing resources until the logging issue is resolved. You can change this behavior so that PingFederate allows transactions to proceed even if logging fails.

|   |                                                                                                                                                                                                                                                                                                            |
| - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | You should only allow transactions to continue during logging failure as a temporary measure while you improve your logging configuration. If you choose to allow transactions to continue potentially unlogged, enable log failure tracking so that you can resolve logging failures as soon as possible. |

## Steps

1. Go to **System > Server > Audit Log Settings**.

2. In the **Audit Log Failure Mode** list, select one of the following:

   * **Block** (default): Transactions fail if logging fails.

   * **Continue**: Transactions are permitted to proceed if logging fails. PingFederate will continue to attempt writing to the log.

3. For **Track Audit Log Failures**, click **On** to track logging failures, or **Off** to allow failures to go untracked.

4. If you click **On**, configure how to track logging failures:

   1. In the **Failure Window** field, enter an integer for the number of seconds to calculate the failure rate for.

   2. In the **Failure Threshold** field, enter an integer for the number of logging failures to allow before sending a notification.

   3. In the **Notification Publisher** list, select a notification publisher instance to use for sending notifications.

      Learn more in [Managing notification publisher instances](help_notificationsendertasklet_notificationsendermanagementstate.html).

   4. Under **Emails to Notify**, click **Add** to add an email address to notify when logging failures exceed the **Failure Threshold** value.

5. Click **Save**