Transaction quota rules
Quick answer
Protect the instance from runaway transactions with quota rules, and read the cancellations correctly.
Key takeaways
- Quota rules protect shared capacity from a single bad transaction
- Set different limits per transaction type
- Raising a limit is the last resort, not the first
- Dedicated integration accounts make quotas targetable
What quota rules do
A transaction quota rule cancels or logs transactions that exceed a duration or count limit, per user or globally. They stop one bad report or one hot integration from consuming all semaphores and taking the instance down for everyone.
Types of protection
Set limits by transaction type: interactive UI transactions, SOAP and REST calls, scheduled jobs. A read only report user should not be able to run a five minute query on the interactive pool.
Reading the aftermath
When users complain that something was cancelled, the log tells you what to fix.
- Check the transaction cancelled log entry for the URL and duration
- Fix the underlying query rather than raising the limit
- Give integrations their own account so quota rules can target them
- Alert on repeated cancellations, they signal a growing problem
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
What is the correct first response to repeated cancellations?
- A. Raise the limit
- B. Investigate and fix the slow transaction
- C. Disable the rule
- D. Add more admins
Show answer
B. Investigate and fix the slow transaction
The rule is a symptom detector, the query is the problem.
Why give integrations their own accounts?
- A. Licensing
- B. So quotas and logs can be targeted per integration
- C. Faster authentication
- D. To avoid ACLs
Show answer
B. So quotas and logs can be targeted per integration
Separate accounts make limits and troubleshooting precise.