Transaction quotas

  • Release version: Yokohama
  • Updated May 8, 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 Yokohama release enable administrators to define policies that limit the resource consumption of different transaction types. These quotas help prevent poorly performing queries and scripts from monopolizing system resources, ensuring balanced system performance. When a transaction exceeds its quota, it is canceled and the user is notified. The Transaction Quotas plugin is enabled by default on all new and upgraded instances.

    Show full answer Show less

    How Transaction Quotas Work

    The system uses a background process called the Quota Manager to monitor and enforce quota rules. The Quota Manager:

    • Regularly obtains a list of active transactions similar to the one in User Administration > Active Transactions.
    • Evaluates each transaction against all quota rules with matching conditions, in order determined by the rule's Order field (lower order rules checked first).
    • Cancels any transaction that exceeds quota limits, such as running longer than the maximum allowed time.
    • Logs information about running and canceled transactions for review.
    • Re-evaluates transactions whenever they change or new quota rules are added.

    The timing between checks is controlled by the system property glide.quota.manager.heartbeat.

    Transaction Cancellation and Logging

    If a transaction exceeds the maximum allowed duration, it is canceled and the user receives a notification explaining the cancellation. A warning is also recorded in the Transaction Cancellation Log, accessible via All > System Logs > System Log > Transaction Cancellation Log.

    Transaction cancellations may occur for various reasons, including:

    • maximum execution time exceeded: Canceled by the Quota Manager thread due to quota limits.
    • canceled by other transaction: Canceled by the session thread that initially issued the transaction.
    • canceled by user request: User manually cancels the transaction via the interface.

    For identifying transactions canceled by quota enforcement, search the cancellation log for messages containing maximum execution time exceeded. Example log entries include details of the transaction and its duration before cancellation.

    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
    .