Rate limiting
Rate limit your sites with highly-customizable rate limit rules, which you can apply across your team’s sites in rulesets.
# Overview
As a Team Owner, you can create rate limit rules in rulesets, which you can then apply to a site’s published or unpublished deploys.
To ensure that a ruleset is always applied to your team’s sites, you can set up a team policy that enforces a ruleset for all new and existing sites.
Team Owners can still create custom rulesets and apply these to individual sites and override the team policy. This lets you set up default rate limiting and also gives you flexibility for adding additional or custom protection for a particular site.
When you configure rate limit rules, you can specify what action should occur when a rate limit is triggered:
- Block: this action blocks requests with a standard 429 status code.
- Rewrite to path: this action rewrites the request path with a new relative path that you specify. For example, you can rewrite requests to your own customized rate limit error page with a relative path such as
/rate_limit_page.html.
When a Team Owner creates, edits, deletes, or applies a rate limiting ruleset, these actions are logged in the Team audit log. Rate limit rules are read-only for the Developer role.
# Use cases
- Mitigate a DDoS attack. While Netlify offers automatic DDoS detection, rate limiting, and blocking to keep your site reliable, you can now preemptively customize rate limit rules for your site and apply these rules to all sites in your team by default with a team policy. Note that Netlify’s automatic DDoS protection can activate before your own custom limits are triggered.
- Protect your backend. Protect your site’s backend by limiting traffic for all requests to your site instead of just requests from certain IP addresses. This helps your site avoid server crashes and slow response times.
- Prevent web scraping. Limit requests from a single IP address or user agent to preserve content integrity and prevent unauthorized access to sensitive information.
- Enforce fair API usage. Limit the number of API calls that a client can make within a 60 second period to prevent API abuse and keep the API available and high-performing for all.
- Reduce bot traffic. Prioritize requests from real site visitors by limiting requests from bots that can overwhelm the server. This is especially important during times of high traffic, such as for flash sales, promotions, or viral content.
- Optimize bandwidth usage. Limit requests that use up a lot of bandwidth, such as requests to access articles and media files, and requests related to data transfer.
- Target a malicious actor. Limit requests to your site based on the number of requests to a domain from a certain IP address.
# Examples
For more detailed examples of how to set up a rate limit rule for different use cases, check out our official Developer Hub guide on safeguarding your sites from abuse.
# Rule conditions
Optimize your rate limit rules for different use cases with different rule conditions, which define when a rate limit rule is triggered.
You can trigger a rate limit rule when values match or equal one or more of the following:
- Connection IP address
- Geolocation
- Request path
- Cookie
- HTTP header
Below are some rule condition triggers and examples of the values they accept.
| Rule condition trigger | Supported value format | Examples |
|---|---|---|
| Connection IP | IP address of either the user accessing the site or the proxy set up to access the site in CIDR notation | 155.255.355.0/24 |
| Geolocation | Text | Enter a country name, then select a country/subregion |
| Path | Text or regex | /api/v1/.* For requests that proxy to an API |
| Cookie | Text or regex | Set session_key to match .* value Will match requests with a session_key value, even if the value for that key is empty |
| HTTP Header | Text or regex | Set Authorization Header to match a specific API token value Bearer ABUSIVE_TOKENCan set up a rule that rate limits a specific API token |
# Published and unpublished deploys
Optimize your rate limit rules for published or unpublished deploys.
A published deploy is the current live deploy at a site’s main URL. Once a different deploy becomes live at the site’s main URL, that deploy becomes the published deploy for that site.
An unpublished deploy can be a Deploy Preview, a branch deploy, or any other deploy not published at your site’s main URL, such as a new production deploy that has not published because you locked an older published deploy.
Learn more in our deploys docs.
# Limitations
The rate limiting feature includes these limits:
- Each ruleset must have at least 1 rule.
- 100 rules maximum per ruleset.
- A maximum of 2 rate limiting rulesets can be set per site — one for published deploys and one for unpublished deploys. You can apply the same ruleset to both or use two different ones.
# How request counts are calculated
By default, Netlify calculates requests globally instead of by region. To set a limit for a specific region, you can add rule conditions that specify the geolocation/subregion you want the rule to apply to.
You can specify how you’d like Netlify to count requests for each rule with our request aggregation options in the Netlify UI.
When calculating requests, there may be a window of time between when a client passes a limit and when Netlify starts enforcing the limit. This latency is minor and expected to be less than a second. Adding rules to your site won’t impact latency when serving assets.
Given all the variations in traffic patterns, we recommend you try different settings to find what works best for your site and site visitors. Some experimentation is especially helpful when considering how much you want to optimize a site’s rate limiting to enforce a hard limit versus a more approximate limit.
# Request aggregation options
When creating a rule in the Netlify UI, under Request aggregation, you can choose between two different ways to calculate requests:
Per domain (default): all site visitors are limited to a shared limit with a specified number of requests per 60 seconds. This option is good for protecting your backend no matter who is visiting your site.
Per domain and IP address: each site visitor is limited to a specified number of requests per 60 seconds. This option is good for targeting potential bad actors.
# Request calculation for rate limiting per domain
When you rate limit by domain, once the number of requests goes above the limit during specified time period, then we start banning the IPs with the highest rate.
For example, if you set a limit of 300 requests, once the site reaches that limit, we ban the IP address with the highest request rate. We then adjust the currently counted requests with the traffic we’ve just banned, so other lower rate IPs are not affected.
This means you may notice more than 300 requests for that time interval because, by banning those high rate IPs, there’s more request budget for other lower rate IPs. This continues until the request rate is under the defined limit.
So if one IP address is behind most of the traffic, then you may detect a seesaw (repeated up and down) traffic pattern in your web traffic monitoring tools.
When calculating the request count, Netlify assigns a weight to IP addresses based on the number of requests and how recently the requests were made. This allows Netlify to prioritize rate limiting IP addresses that are currently generating the largest amount of traffic until the desired limit is reached.
# Example request calculation for set of rules
To explain how we calculate requests, here’s an example of ruleset:
Rule 1: Protect homepage
- Rule triggered when requests match path
/index.html - Limit: 10 requests per 60 seconds
- Action: Block and return 429 error
- Request aggregation: By domain (default)
Rule 2: Limit known API abusers
- Rule triggered when requests have the header
Authorizationthat equalsBearer ABUSIVE-TOKEN. - Limit: 5 requests per 60 seconds
- Action: Block and return 429 error
- Request aggregation: By domain (default)
If the example ruleset above is applied to your site and your site has requests to path /index.html with an Authorization header with the same Bearer ABUSIVE-TOKEN value from rule 2, then we will count requests for both rules and start applying the first rule that has been triggered, by order of the definition you set in the UI.
- If there are 7 requests per 60 seconds, then rule 2 is applied since rule 1’s threshold hasn’t been crossed
- If there are 10 requests per 60 seconds, then rule 2 is applied, since rule 1’s threshold hasn’t been crossed (you need 11 requests to cross it)
- If there are 20 requests per 60 seconds, then rule 1 is applied, since rule 1’s threshold has been crossed and is defined first. Although, rule 2 is triggered as well with 20 requests, we only apply one action (block with a 429 status code) per request.
# Manage rulesets
Rate limit rules are managed in rulesets, which can be edited and applied to sites. Any changes in a ruleset take effect on all sites where the ruleset applies.
Only Team Owners can create, edit, or delete a ruleset.
A site can have a maximum of two rulesets applied, one for published deploys and one for unpublished deploys.
# Create a ruleset
To create a ruleset:
As a Team Owner, go to
.Select Create ruleset.
Enter your ruleset name and description.
Select Add a rule and follow the prompts. You can add up to 100 rules for a ruleset. When you add a rule, you can specify the following:
- Rule condition: defines when the rule is triggered. For an overview of your options, check out the rule conditions table.
- Limit: defines the number of requests allowed per 60 seconds.
- Request aggregation: defines how we calculate and apply the limit for your rule. Includes Per domain (default) (ideal to protect your site’s backend) or Per domain and IP address (ideal to target a potential bad actor).
- Action: defines what happens when the rate limit threshold is crossed. The action is applied for 60 seconds. Currently supports these actions:
- Block: this action blocks access to the site and returns a
429status code. - Rewrite to path: this action rewrites the request path with a new relative path that you specify. For example, you can rewrite requests to your own customized rate limit error page with a relative path such as
/rate_limit_page.html.
- Block: this action blocks access to the site and returns a
Confirm your rule by selecting Add rule.
Optionally, repeat steps 4 and 5 to add more rules to your ruleset as needed.
Save your ruleset.
Next, you can make your ruleset the team policy or apply it to an individual site.
# Edit a ruleset
To edit a ruleset:
As a Team Owner, go to
.From your Team rulesets, select the ruleset you want to edit.
Under your ruleset description, choose Edit ruleset.
Make your changes and save.
Your ruleset’s updates will take effect in all sites where the ruleset is applied.
# Delete a ruleset
To delete a ruleset:
As a Team Owner, go to
.From your Team rulesets, select the ruleset you want to delete.
Under your ruleset description, choose Delete ruleset.
The ruleset will no longer apply to your sites.
# Apply a ruleset to a site
Only Team Owners can apply a ruleset to a site from the Site Configuration page in the Netlify UI.
To apply a ruleset to a site:
For the desired site, go to
.Under Rulesets for [site name], select Manage rulesets.
Choose a ruleset option to apply to your site’s published deploys and/or unpublished deploys and select Save. If you already have a team policy ruleset configured, then you can override the team policy ruleset with a different ruleset.
# Configure a team policy ruleset
To rate limit your team’s sites with a default ruleset, configure a team policy for your site’s published deploys and/or unpublished deploys.
The team policy ruleset applies to all new and existing sites in your team. A Team Owner can override the team policy ruleset with a different ruleset for one site at a time.
A maximum of 2 rate limiting rulesets can be set per site — one for published deploys and one for unpublished deploys. You can apply the same ruleset to both or use two different ones.
As a Team Owner, to configure a team policy:
Go to
.Select Configure team policy.
Choose a ruleset option for published deploys and/or unpublished deploys, then save your changes.
Did you find this doc useful?
Your feedback helps us improve our docs.