Transaction quotas

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Transaction quotas

    Transaction quotas in ServiceNow enable administrators to define policies that limit the resource consumption of different types of transactions. When a transaction exceeds these quotas, it is automatically canceled to prevent performance degradation across the system. This feature helps maintain system stability by ensuring no single transaction monopolizes resources, thereby allowing other transactions to proceed efficiently.

    Show full answer Show less

    The Transaction Quotas plugin is enabled by default on all new and upgraded ServiceNow instances.

    How Transaction Quotas Work

    • A background process called the Quota Manager continuously monitors active transactions similar to those listed in User Administration > Active Transactions.
    • The Quota Manager evaluates each transaction against defined quota rules in order of their priority (determined by the Order field), checking for any violations.
    • If a transaction exceeds a quota condition—such as running longer than the allowed maximum duration—it is canceled immediately.
    • The Quota Manager reevaluates transactions when they change or when quota rules are updated.
    • Transaction cancellation events and running transactions are logged for administrative review.
    • The frequency of these checks is governed by the system property glide.quota.manager.heartbeat.

    Transaction Cancellation and Monitoring

    When a transaction is canceled for exceeding the quota, the user receives a notification explaining the reason. Each cancellation is also recorded in the Transaction Cancellation Log, accessible via All > System Logs > System Log > Transaction Cancellation Log.

    Cancellation log messages can indicate various causes:

    • maximum execution time exceeded: Cancellation by the Quota Manager background thread due to quota violation.
    • canceled by other transaction: Cancellation initiated by the session thread that issued the transaction.
    • canceled by user request: Cancellation triggered manually by the user.

    To specifically identify transactions canceled by quota violations, search the Transaction Cancellation Log for messages containing "maximum execution time exceeded."

    Transaction quotas allow you to define a quota policy for different types of transactions. A transaction quota cancels any transaction in violation of the policy and notifies the user of the cancellation.

    Administrators can set transaction quotas to prevent poorly performing queries and scripts from consuming system resources. This ensures that no transaction consumes enough resources to prevent other transactions from running. Administrators can also view cancellation log messages to identify transactions that might consume excessive resources.

    The Transaction Quotas plugin is active by default on all new and upgraded instances.

    How transaction quotas work

    Transactions use the Quota Manager, which is a background thread that cancels transactions according to transaction quota rules. The Quota Manager performs the following actions.
    1. Obtains a list of active transactions, similar to the list under User Administration > Active Transactions.
    2. Cycles through each transaction and checks all quota rules with conditions matching the transaction. The first occurrence that exceeds any of the quota limitations triggers a transaction cancellation. If a transaction changes or there is a new quota rule, the Quota Manager re-evaluates the transaction.
      Note:
      The Order field on a quota rule affects the order in which the quota rules are checked. The Quota Manager checks lower-order rules first (for example, order 80 before order 90), but ultimately checks all rules. This might have marginal performance implications, depending on the conditions of the rules involved.
    3. Cancels the transaction if it has been running longer than the specified quota maximum.
    4. Logs the running transactions.
    5. Sleeps until the next heartbeat, which is controlled by the glide.quota.manager.heartbeat system property.

    Transaction cancellation from exceeded quotas

    When a transaction runs longer than the maximum duration specified by a quota rule, the user is notified of the cancellation and the reason.

    Additionally, a warning is logged in the Transaction Cancellation Log whenever a transaction is cancelled due to exceeded quotas. To view the Transaction Cancellation Log, navigate to All > System Logs > System Log > Transaction Cancellation Log.

    Transaction cancellation examples

    Transactions can be canceled for more than one reason. Look for the following indicators.

    • maximum execution time exceeded: This message appears when the glide.quota.manager threads cancels the transaction.
    • canceled by other transaction: This message appears when the transaction was canceled by the session thread that initially issued it, and not by the glide.quota.manager thread.
    • canceled by user request: This message appears when the user selected the red X button to cancel the running transaction.
    If you are looking for transactions that were canceled by glide.quota.manager, search for the [Message] [Contains] [maximum execution time exceeded] combination. For example:
    Cancelling transaction /home.do - Default-thread-11.0 (maximum execution time exceeded): Thread Default-thread-11.0 (Default-thread-11.0, F530DD111B11111111FC031767DA158E), after 30000ms
    .