ServiceNow Rate Limit Explained

What Rate Limits Are and Why They Exist

A rate limit in ServiceNow (and most cloud services) is a restriction on how many API calls can be made in a given time period. Rate limits exist to protect system stability: if one client or process makes millions of API calls, it can overwhelm the server, degrade performance for other users, or cause the service to become unavailable. Rate limits force clients to use APIs responsibly and ensure fair access for all clients.

Rate limits are not arbitrary; they are calculated based on system capacity, expected usage patterns, and subscription level. A high-volume customer with a premium subscription might have higher rate limits than a small customer. Rate limits apply to categories of API calls (REST API, SOAP, database queries) and sometimes at more granular levels (rate limits per endpoint, per user, per authentication token). ServiceNow publishes rate limits in documentation and in API responses so clients know what they are.

How Rate Limits Work in Practice

When a client makes API calls, ServiceNow tracks the count. If the rate limit is 300 calls per minute, the first 300 calls succeed. Call number 301 is rejected with an HTTP 429 (too many requests) error. The client must wait until the current minute is over to make more calls. Rate limits are typically rolling windows: if you made 300 calls in the first 50 seconds, you cannot make more calls in that same minute, but at the 50-second mark of the next minute, you can resume.

API responses include rate limit information: how many calls you have remaining in the current window, when the window resets, and how many calls have been consumed. Clients can use this information to manage their behavior: if only 10 calls remain and more work needs to be done, pause before making more calls and wait for the window to reset. If a client ignores rate limits and keeps making calls after hitting the limit, those calls are rejected, wasting bandwidth and slowing down work.

Common Scenarios and Misconceptions

A frequent misconception is that hitting a rate limit is a failure or indicates the system is broken. In reality, rate limits are working as designed. If your process is consistently hitting rate limits, it indicates your process is making too many API calls for the allocated quota. Solutions include: optimize the process to make fewer calls (batch multiple changes into one call rather than one call per change), implement caching (store recently fetched data locally rather than fetching repeatedly), or request a rate limit increase if your use case genuinely requires more calls than your current allocation.

Another misconception is that rate limits are the same for everyone. In reality, different subscription levels have different limits. A trial customer might have a 100 calls per minute limit. A standard customer might have 500 calls per minute. A premium customer might have 2,000 calls per minute. If your use case requires more calls than your current allocation, contact your account manager about upgrading your subscription or requesting a limit increase.

A third misconception is that rate limits apply only to external API clients. In reality, limits apply to all API calls regardless of source: integrations, workflows, custom code, and even the web UI (which makes API calls behind the scenes). A workflow that loops through 10,000 records and updates each one individually could hit rate limits. The solution is to optimize the workflow or break the work into batches to avoid hitting limits.

Handling and Optimizing for Rate Limits

If a client hits a rate limit, the proper response is to back off and retry. Most clients implement exponential backoff: first failure, wait 1 second and retry. Second consecutive failure, wait 2 seconds and retry. Third consecutive failure, wait 4 seconds and retry. Eventually either the request succeeds or the number of retries is exhausted. This approach prevents hammering the service and gives the service time to recover if it is temporarily overloaded.

Long-term optimization requires reducing the number of API calls your process makes. Instead of fetching a single record per API call, fetch multiple records in a batch call. Instead of making separate calls to update different fields, update multiple fields in a single call. Instead of making the same query repeatedly, cache results. Efficient API usage respects rate limits and is generally faster and cheaper (some platforms charge by API call volume).

Monitor your API usage and rate limit consumption. ServiceNow provides reports showing API calls per day and API calls per endpoint. If you are consistently near your rate limit, investigate which processes are making the most calls and optimize those first. If you consistently exceed your limit, request a limit increase and justify the business need. Limit increases are not free (premium subscriptions are more expensive) but are available for customers with genuine high-volume needs.

Sizing a bulk job against a quota before it starts

Integration engineers often discover the rate ceiling in the middle of a load, when a nightly import has processed two thirds of its records and begins to fail. A short calculation before the first run prevents that. Count the calls the job makes per record, including the lookups it performs to find the record and the calls that confirm the update, then multiply by the record count and by the number of runs per window. Compare the result with the quota that applies to that identity, not the quota printed for the platform in general, because a shared service account may already be spending part of the same allowance. If the total exceeds the window, the job needs to change shape before it is scheduled, not after it fails.

Backing off in a way that does not multiply the problem

A retry loop that is too eager turns a throttled job into a self-inflicted outage. When many workers receive the same throttle response and retry on the same schedule, they return together and are throttled again. The usual remedy is to add jitter, a small random offset to each wait, so the workers spread out. The loop should also have a ceiling, so that a long throttle window ends in a parked job with a clear status rather than an unbounded wait. Read the wait that the platform suggests in its response when one is provided, since it reflects the actual window better than a guess.

1. Classify the response first. A throttle response means the request is valid and should be retried later. An authentication failure or a malformed request should not be retried at all.
2. Wait for the suggested interval where one is returned, and add a random offset of a few seconds to avoid synchronised retries.
3. Cap the total time spent retrying a single record, and move the record to a parked state when the cap is reached.
4. Keep a count of parked records per run, and stop the job early if that count passes a level the owner has agreed in advance.
5. Resume from the last committed position rather than restarting from the top, so a throttle does not repeat work already done.

Reading the signs that a job is hitting the ceiling

Throttling rarely announces itself as a single failure. It shows as a rising count of retries in the job log, as runs that take longer each week without any change in record volume, and as an integration that completes but leaves a tail of parked records. Watch the gap between the start of a run and the time its last record completes, since that gap widens first. A second signal is a failure that appears only at certain hours, which can mean another consumer is using the same allowance at those times. Put these measures on the same view as the job itself, so the cause is visible next to the symptom.

When to stop tuning and change the design

Tuning the calls only goes so far. If a job needs to process a volume that will keep growing, the better option is usually to change how it learns about changes. Event-driven delivery from the source system, where the platform supports it, removes most of the polling that consumes an allowance without adding value. When the source cannot notify, consider a staging table that absorbs the bulk of the reads, so the integration reads from its own store most of the time. Each of these moves has a cost in build effort and in new failure points, so compare the options against the volume you expect in a year rather than the volume you have today.

When asking for more allowance is the right answer

Request a higher allowance when the job is already efficient, the volume is genuine and the business owner can name the process that depends on it. Ask for it with the calculation in hand: the calls per record, the record count, the windows, and the other consumers of the same identity. A request backed by that arithmetic is taken more seriously than a general complaint that the platform is slow, and it shows whether the increase will actually solve the problem or only postpone it.

Does a throttled request still count against the quota?

Usually it does, so a job that keeps retrying immediately can use up the allowance it is trying to wait for. Honor the wait suggested in the response, and avoid tight retry loops that generate rejected calls.

Should batch calls be preferred even when they are harder to debug?

Batching reduces the call count, but a failed batch can make it unclear which record caused the problem. Log the record identifiers within each batch, and fall back to single calls for a batch that fails so that one bad record does not hold up the rest.

How should the job report its own throttling?

Write a summary at the end of each run that gives the record count, the parked count, the total retry time and the highest wait observed. A summary like this turns a vague sense of slowness into a figure that can be trended and discussed with the owner.

Can a scheduled job safely run at the same time as an interactive user session?

It can, but the job should be scheduled away from the hours when interactive use peaks, and its ceiling should leave room for users. Reserving part of the allowance for interactive work is a sensible rule for any shared identity.