Rate limiting: how we stop one visitor from taking your site down
What rate limiting is, where we apply it on a business website, how the limits are chosen, and what a visitor sees when they hit one.
The short answer
Rate limiting caps how many requests one source can make in a given period. Without it, a single script can submit a contact form ten thousand times, try ten thousand passwords against a login, hammer a search endpoint or call a function that costs money on each run, and either take the site down, run up a bill or fill your inbox and CRM with rubbish. Static pages rarely need limits because serving a cached file costs nothing; the limits go on the things that cost money or create risk: forms, logins, APIs, search and any serverless function. We set the limits from real traffic, generous enough that no genuine visitor ever meets them and tight enough that a flood is stopped in seconds, apply them per source at the network layer and inside the functions, and make sure a visitor who does hit one sees a clear message and a retry rather than a silent failure.
Where limits go and why
| Endpoint | Typical limit shape | Protects against |
|---|---|---|
| Contact and quote forms | A few submissions per source per minute, and a daily cap where the counter is shared | Spam floods, inbox and CRM pollution, email sending costs |
| Login and password reset | A handful of attempts per account and per source, then a pause | Brute-force and credential stuffing |
| Search on the site | Tens per minute per source | Scraping and function costs |
| Public API endpoints | Per key and per source, with quotas | Abuse, scraping, runaway integrations |
| Serverless functions in general | Per source, plus a global ceiling | Runaway bills from floods or bugs |
| Newsletter sign-up | A few per source per hour | List bombing, bounce rate damage |
| Static pages | Usually none; the network layer handles floods | Not needed; cached files cost nothing |
Setting the limits
- Measure real behaviour: how often does a genuine visitor submit, log in or search? Logs answer this.
- Set the limit well above the busiest genuine pattern, and lower it only with evidence.
- Apply at the edge for broad rules and in the function for precise ones, such as attempts per account.
- Choose the response: a clear message with a retry time, and a proper status code so automated clients understand.
- Log every limit event with source and endpoint; review weekly at first.
- Add a global ceiling on costly functions so a distributed flood still has a bound.
- Combine with anti-bot checks on forms so most abuse never reaches the limit.
What the visitor sees
Almost always nothing, because limits are set above genuine use. On the rare occasion a real visitor meets one, the page says plainly that too many requests were made and when to try again, keeps what they typed, and offers another way to reach you. The limit is a safety feature; it must never look like the site is broken.
What this means for you
Rate limiting keeps one source from flooding the parts of your site that cost money or create risk. Put limits on forms, logins, search, APIs and functions, set them from real traffic so genuine visitors never notice, apply them at the edge and in the code, log the events, and give anyone who hits one a clear message. It is a small piece of configuration that prevents a whole class of bad nights.
Frequently asked questions
Will rate limiting block real customers?
Not if set from real traffic. A genuine visitor submits a form once or twice, tries a password a handful of times, searches a few times a minute. Limits are set well above those numbers and applied per source, so one flood does not affect others. When someone does hit a limit, they see a plain message with a retry, and the event is logged so the limits can be tuned.
Where do the limits run?
As close to the visitor as possible: at the network layer in front of the site for broad rules, and in the functions themselves for the specific action. Counting precisely across every instance needs a shared counter; a counter held inside one function instance limits each instance separately, which is a real limit but not an exact one. Limits at the edge stop floods before they reach anything that costs money; limits in the function protect the specific action.
Is rate limiting the same as DDoS protection?
It is one layer of it. Rate limiting stops one source, or a moderate number of sources, from overusing a specific action. A large distributed flood is absorbed and filtered by the network layer in front of the site. Together with a static architecture and provider caps they form the protection; rate limiting alone would not stop a large attack, and the network layer alone would not stop a slow abuse of a form.
Sources
- OWASP Cheat Sheet Series: Denial of Service Cheat Sheet (accessed 2026-09-12)