Skip to content

Shield: rate limiting

Rate limiting caps how many requests a single client can make to your site within a time window. It's the most effective way to blunt login brute-force attempts, scraping, and abusive request floods without blocking legitimate visitors. This guide walks through adding, editing, and removing rate-limit rules from the dashboard.

Rate limiting is part of Shield, so the rules you create here apply at the CDN edge, before traffic reaches WordPress.

Before you start

  • A site that is already provisioned
  • A plan that includes Shield, with Shield activated for the site — if Shield isn't active, the Rate Limits page shows a card titled "Shield isn't active for this site" with an Activate Shield button. See Shield overview.
  • Permission to manage the site

Longer time windows may not be available on your plan

The Timeframe list offers every window to everyone, but how long a window you can actually save depends on the Shield plan behind your site. If yours doesn't allow the one you picked, the save is rejected and the edge's own message appears above the form, naming the longest timeframe you can use and pointing you at an upgrade. Nothing is saved when that happens — change the window, or upgrade the site's plan, and save again.

How a rate-limit rule works

A rule counts requests that match a condition and fires an action once the count crosses a threshold inside the timeframe:

  • Match — which requests are counted (for example, requests whose URL contains /wp-login.php).
  • Threshold + timeframe — how many matching requests are allowed before the action fires, and over what rolling window.
  • Action — what happens once the threshold is crossed: Rate Limit (block further requests), Challenge (present a browser check), or Log (record only, don't block).
  • Count by — the attribute used to group the count, such as the client's IP address.

Add a rate-limit rule

  1. Open the site's Rate Limits page. In the left sidebar, open My Sites and select your site. In the site's sidebar, expand the Shield dropdown and click Rate Limits.

  2. Start a new rule. Click + New rate limit. If you don't have any rules yet, the page shows a "No rate limit rules" empty state with the same button.

  3. Name the rule. Enter a Rule name (required) — for example, Login brute force. You can add an optional Description to note what the rule protects against.

    Letters, numbers and spaces only

    Both Rule name and Description accept only letters, numbers, and spaces. Punctuation you'd reach for naturally — hyphens, underscores, dots, slashes — and accented characters are all rejected, and so is the save: Login brute-force fails where Login brute force succeeds. The save then fails with a message ending "Rule name can only contain letters, numbers, and spaces."

  4. Choose the action. Set Action to one of:

    • Rate Limit — blocks further matching requests once the threshold is reached.
    • Challenge — presents a browser check instead of blocking outright.
    • Log — records matches without blocking, useful for testing a rule before you enforce it.

  5. Define what to match. Set the Match variable (the part of the request that's counted, such as REQUEST_URI), the Operator (how the value is compared, such as Contains), and the Match value (the string or pattern, such as /wp-login.php). Leave Match value blank to count all requests for the selected variable.

  6. Set the threshold and timeframe. Enter the Request count — the number of matching requests allowed before the action fires — and choose the Timeframe, the rolling window the count is measured over. Timeframe is a fixed list, and every option is spelled in seconds: 1 second, 10 seconds, 60 seconds, 300 seconds, 900 seconds, and 3600 seconds.

  7. (Optional) Adjust advanced options. Expand Advanced options to set:

    • Severity — the level recorded in your event logs when the rule fires (Notice, Warning, or Critical).
    • Block duration — how long an offending source is blocked after exceeding the threshold. Leave it on Use Bunny default unless you have a specific value in mind.
    • Count by — the attribute used to group request counts. IP address is the standard choice; other options include Host, Country, City, ASN, Organization, JA4 fingerprint, and IP + JA4.

  8. Save the rule. Click Save rule. On success you're returned to the Rate Limits page and the new rule appears in the list.

The Rate Limits page lists each rule under the Rate Limit Rules heading, showing its Name, Match, Threshold (rendered as <count> req / <seconds>s), and Action (a colored badge). Each row has Edit and Delete controls.

The same rate-limit rules can be created over the REST API (and the MCP server), subject to the same plan gating:

curl -H "Authorization: Bearer $CLOUDPRESS_TOKEN" -H "X-Auth-Account: $ACCOUNT_ID" \
  https://my.cloudpress.com/api/sites/$SITE_ID/shield/rate_limits

See the Shield API reference for the full request shape, the match-variable vocabulary, and the action/counter-key enums.

Test with Log before you Block

If you're not sure a rule will catch only the traffic you intend, set its Action to Log first. Shield records what would have matched without blocking anyone. Review the matches on the Security Events tab, then switch the rule to Rate Limit once you're confident.

Edit a rule

  1. On the Rate Limits page, find the rule in the list and click Edit.
  2. Change any field — name, action, match condition, threshold, timeframe, or the advanced options.
  3. Click Save rule.

Delete a rule

  1. On the Rate Limits page, click Delete on the rule's row.
  2. Confirm in the "Delete rate limit rule?" dialog. Deletion is permanent and cannot be undone.

A rejected save is usually a plan limit or a stray character

The two things that most often stop a save are a timeframe your plan doesn't allow (above) and a rule name or description containing something other than letters, numbers, and spaces. When a save is rejected you stay on the form with everything you typed still in place, and the reason appears in a banner above it. Read that banner rather than assuming the save succeeded — see Shield overview.

Next steps