Platform performance · LessonBy Neelima, ServiceNow Architect · Published · ServiceNow · all levels
Transaction quota rules
Protect the instance from runaway transactions with quota rules, and read the cancellations correctly.
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
Practice challenge
+0 XPStreak ×0
Question 1 of 2
What is the correct first response to repeated cancellations?
Frequently asked questions
Do quota rules block legitimate long reports?
They can, which is why long reports should be scheduled rather than run interactively.
Where do I see cancellations?
The transaction log and the syslog entries created when a rule fires, including the user and the URL.