Rate Limiting¶

Traffic Rate Limiting controls how many HTTP requests a caller may make to a service during one or more time windows. It protects upstream services from bursts and sustained overuse; it is separate from usage-based Service Limits.

Screenshot needed

Add a screenshot of the Rate Limiting list page.

When to use Rate Limiting¶

Use Rate Limiting when you need to:

view existing rate limit rules;
create a new rate limit;
update a rule;
reduce the chance of overload or unexpected usage.

Rate Limiting list¶

The list shows Status, Service, request ceilings for Second, Minute, Hour, Day, Month, and Year, Limit By, and Created date. A dash means that no ceiling is set for that time window. At least one time-window value must be supplied.

Screenshot needed

Add a screenshot of the Rate Limiting table showing rule names and actions.

Create a rate limit¶

Open Traffic Management.
Select Rate Limiting.
Select New Service Rate Limit.
Select the service and choose whether the rule is enabled.
Enter the maximum number of requests for at least one time window: second, minute, hour, day, month, or year.
Select Limit By to define how callers receive separate counters.
Complete the header name or path when required by that choice.
Review fault-tolerance and policy settings with the platform owner.
Save the rule and test it with controlled traffic.

Field guide¶

Field	Required	What to enter	Notes
Enabled	Yes	Whether the rule is actively enforced.	Create disabled first if testing must happen in a controlled window.
Service	Yes	The gateway service protected by the rule.	Similar service names may point to different upstreams.
Second to Year	At least one	Maximum requests for that period.	Blank periods are not limited by this rule. Enter non-negative whole values.
Limit By	Yes	How separate counters are assigned, such as consumer, credential, IP, header, or path when offered.	Without authentication, client IP may be used; shared proxies can cause many users to share a counter.
Header Name	Conditional	Header used to distinguish callers.	Required when limiting by header. It must be reliably supplied and difficult to spoof.
Path	Conditional	Request path used for the counter.	Required when limiting by path. Confirm matching behavior before rollout.
Fault Tolerant	If shown	Behaviour when the counter store is unavailable.	Follow the approved availability and security design.

Choose suitable time windows¶

A per-second limit controls bursts, while per-day or per-month limits control sustained volume. When several windows are configured, a caller must remain below all of them. For example, a caller can reach a strict per-second limit even when still far below the daily total.

Start from measured normal and peak traffic, not a guess. Allow for retries, scheduled jobs, traffic through shared IP addresses, and legitimate bursts.

Edit a rate limit¶

Open the rule from the list, update the values, and save. After deployment, monitor rejected requests and upstream health. If legitimate users are blocked, identify which configured window was reached and which Limit By value grouped their requests before increasing the limit.

Advanced Redis policy settings determine where counters are stored and how securely the portal connects to that store. Change hosts, password, SSL, database, SNI, or timeout only with approved infrastructure values.

Warning

Very strict rate limits can block normal users. Start with the agreed limit and monitor usage after saving.