Example dataInvented site example.edu. Not a customer. Not live traffic.
Example WAF Cybersecurity Advisor
The WAF that tells you what's safe to block.
Rules start in count. After about 24 hours, the Advisor reads the window and recommends Promote, Hold, or Needs allowlist — with the evidence, the "If you promote" preview, and an exact-path allowlist draft when a real workflow is matching. You still click Promote. It never flips a rule to block on its own.
The Promote and Undo buttons below are that human click. On this example they do not change a rule.
A Virtual patch available card names a known exploit class and the managed rule group that watches it. Add in count mode is a click. On this example that button does not change a rule.
Walk through Example University is the same three cards on one fictional Tuning view. Example data.
- PromoteQuiet in the window — safe to start blocking after you click.
- HoldStill watching or noisy — keep counting.
- Needs allowlistLooks like real visitors — allow that traffic first.
Example dataInvented counts for example.edu. Not a customer. Not live traffic.
Advisor
Tuning is count → promote. Rules start in count. After 24 hours, the Advisor names what's safe — you click once. Nothing auto-blocks. It never flips a rule to block on its own. Rule-based checks on this site's logs — the same evidence always gives the same answer.
The 24-hour window is over. Promote quiet rules, or hold / allowlist anything noisy.
Count window
Each managed rule in count is on this track. Counted hits and site requests are the shared 24-hour CloudWatch rollup, so they match Analytics and the Advisor. A missing series says not confirmed, not zero.
- StartRules enter count
- 12hseries
- 24hdecision
- 7dyour click
- Site requests in 24h: 4,000
- CloudWatch series: 24 hours
- In count for 30 hours, since this site was protected
- Linux server exploitsIn count for 30 hours, since this site was protected
- Counted hits in 24h: 12
Before PromoteNothing else. The Advisor can say Promote.
What happens next. Click Promote if you want this rule in block. The samples are attacks and the count is within 8× the sample rows. The Advisor does not flip the rule.
- Common attacks (OWASP)In count for 30 hours, since this site was protected
- Counted hits in 24h: 620
Before Promote- A count under 50 and a share under 15% of site requests, with every sample an explained attack. An explained attack at 15% or more stays on Hold.
What would change this. the count has to fall under 50 and the share under 15 percent before an explained attack can say promote; this size stays on hold
What happens next. Hold this rule. A large share of traffic often includes real visitors. An explained attack at this share stays on Hold too.
- Known exploitsIn count for 30 hours, since this site was protected
- Counted hits in 24h: 64
Before Promote- An allowlist for the known-good path, saved by you, before this rule can be promoted.
What would change this. add an exact-path allowlist if this is your own form
What happens next. Allow that path if you recognize it, then come back. The Advisor does not write the allowlist. Promote stays your click.
Virtual patch available
Example dataInvented advisory. Not a customer. Not live traffic.
A managed rule group can watch this class in count. You click Add in count mode. A rule that is already on stays as it is. Nothing here blocks on its own.
Catalog 2026.10.1
Log4Shell-style JNDI strings
RelevantJNDI lookup strings in a header, query, or path.
Drupalgeddon-style form API probes
General advisoryForm API arrays such as a render callback on a user form.
WordPress plugin and xmlrpc probes
RelevantPlugin paths and xmlrpc calls used to look for weak plugins.
Shellshock
General advisoryA shell function prefix in a header or query, the Shellshock shape.
Rule-based notes from this count window. You still click once.
- SQL injection is pinned to version Version_1.2. It was following AWS's default, which is the version this pin records. A later default change will not change rules already blocking.
1 ready to promote · 1 needs an allowlist · 1 on hold.
- PromoteQuiet in the window — safe to start blocking after you click.
- HoldStill watching or noisy — keep counting.
- Needs allowlistLooks like real visitors — allow that traffic first.
- Linux server exploitsNew protectionPromote
AWS published Linux server exploits version Version_2.1 (this site was on Version_2.0). The group stays in count.
Linux server exploits (linux_exploits) counted 12 hit(s) in the 24-hour window, and every sample looks like a probe (GET /.env).
Promoting blocks those attack shapes, not a known-good login or payment path. You still click Promote — the Advisor does not flip the rule.
Evidence- 24h window
- Counted 12
- GET /.env
Top paths in the sample- 3GET /.env
- 2GET /wp-config.php
- 1GET /.git/config
Sample rows only. Counted 12 is the full 24h window.
Sample requests- GET /.env · 203.0.113.xx · attack
- GET /wp-config.php · 203.0.113.xx · attack
- GET /.git/config · 198.51.100.xx · attack
If you promote- 12 counted request(s) on Linux server exploits in this 24h window would start being blocked.
- Includes GET /.env.
- Only this rule switches to block. Undo puts it back in count — we do not auto-rollback.
- Common attacks (OWASP)Hold
Low confidence to promote — review the evidence first. You still click once.
Common attacks (OWASP) (common_attacks) flagged a large share of requests (620 counted) in the 24-hour window.
That pattern often includes real campus traffic — LMS, registration POSTs, monitoring, CMS, or SSO paths. Keep it in count until you confirm the hits are abuse, not students or editors. The Advisor will not promote this for you.
Blocking. This rule is at least 15% of site requests, and the samples are not an explained attack. This rule is about 16% of site requests. This rule counted 620 hits. A large share often includes real visitors.
What would clear this. A known-good form becomes Needs allowlist. An explained attack at this share stays Hold. Promote would need the count under 50 and under 15%, with every sample an explained attack.
Next look. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. Investigate one matching request. That asks a person to look at that request. It does not promote this rule, and it does not change this Hold.
Evidence- 24h window
- Counted 620
- GET /search
Top paths in the sample- 2GET /search
- 1GET /calendar
- 1GET /news/story
Sample rows only. Counted 620 is the full 24h window.
Sample requests- GET /search · 203.0.113.xx
- GET /calendar · 203.0.113.xx
- GET /news/story · 198.51.100.xx
- Known exploitsNeeds allowlist
Low confidence to promote — review the evidence first. You still click once.
Known exploits (known_exploits) counted POST /saml/acs.
It looks like SSO in the 24-hour window. Allow that path before you promote. You still click — the Advisor does not block.
What would change this. add an exact-path allowlist if this is your own form
Evidence- 24h window
- Counted 64
- POST /saml/acs
Top paths in the sample- 4POST /saml/acs
Sample rows only. Counted 64 is the full 24h window.
Sample requests- POST /saml/acs · 192.0.2.xx · SSO
False-positive risk: SSO.
Allow this pathAllow this path before you promote. The rule stays in count until you click.
Allow POST /saml/acsWhat this lets through- POST /saml/acs · SSO · 192.0.2.xx
- Allows POST /saml/acs exactly.
- Only Known exploits skips that traffic. Other protections still inspect it.
- This does not turn the rule off. Count and block stay as they are until you promote.
- No attack sample in this evidence. Other paths stay inspected.
Known exploits counted this traffic. The exception skips only what the preview says.
- Review what this lets through and what stays blocked.
- Save the exception. Nothing is written before that.
- This rule is checked again after the save. Promote is still a separate click.
Count mode does not block. After Promote, blocks are real. Blocked counts are the current 24h window. Sampled blocks are log rows at or after the promote time. Put a rule back in count if these are your visitors. We do not do that for you.
- Blocked 27 in 24h
- Sampled blocks since promote: 2
Sampled blocks since you promoted look like attacks. This check is not calling that a false positive.
Example of a rule the count window would Promote. The Advisor holds it because the owner undid it after checkout callbacks were blocked. Still example data.
Example dataInvented Undo on Sept 30, 2026. Not a customer. Not live traffic.
Advisor
Tuning is count → promote. Rules start in count. After 24 hours, the Advisor names what's safe — you click once. Nothing auto-blocks. It never flips a rule to block on its own. Rule-based checks on this site's logs — the same evidence always gives the same answer.
Nothing is ready to promote yet — 1 on hold. You undid Linux server exploits on Sept 30, 2026 after checkout callbacks on POST /wc-api/WC_Gateway_Paypal were blocked.
Count window
Each managed rule in count is on this track. Counted hits and site requests are the shared 24-hour CloudWatch rollup, so they match Analytics and the Advisor. A missing series says not confirmed, not zero.
- StartRules enter count
- 12hseries
- 24hdecision
- 7dyour click
- Site requests in 24h: 4,000
- CloudWatch series: 24 hours
- In count for 30 hours, since this site was protected
- Linux server exploitsIn count for 30 hours, since this site was protected
- Counted hits in 24h: 12
Before PromoteNothing else. The Advisor can say Promote.
What happens next. Click Promote if you want this rule in block. The samples are attacks and the count is within 8× the sample rows. The Advisor does not flip the rule.
Rule-based notes from this count window. You still click once.
What the Advisor remembers
You undid Linux server exploits on Sept 30, 2026 after checkout callbacks on POST /wc-api/WC_Gateway_Paypal were blocked.
1 on hold.
- PromoteQuiet in the window — safe to start blocking after you click.
- HoldStill watching or noisy — keep counting.
- Needs allowlistLooks like real visitors — allow that traffic first.
- Linux server exploitsNew protectionHold
AWS published Linux server exploits version Version_2.1 (this site was on Version_2.0). The group stays in count.
Low confidence to promote — review the evidence first. You still click once.
You undid Linux server exploits on Sept 30, 2026 after checkout callbacks on POST /wc-api/WC_Gateway_Paypal were blocked.
Remembered. You undid Linux server exploits on Sept 30, 2026 after checkout callbacks on POST /wc-api/WC_Gateway_Paypal were blocked.
What would clear this. New evidence that would clear this is a later sample of /wc-api/WC_Gateway_Paypal that is only an attack, with no checkout callbacks in the sample. The Advisor will not Promote, allow, or relax a rule from that. Clear this lesson if you want the Advisor to forget the decision.
Evidence- 24h window
- Counted 12
- GET /.env
Top paths in the sample- 3GET /.env
- 2GET /wp-config.php
- 1GET /.git/config
Sample rows only. Counted 12 is the full 24h window.
Sample requests- GET /.env · 203.0.113.xx · attack
- GET /wp-config.php · 203.0.113.xx · attack
- GET /.git/config · 198.51.100.xx · attack
Example of the first day, before CloudWatch has confirmed a series. Counted hits say not confirmed, not zero. Still example data.
Example dataInvented new site. Series not confirmed. Not a customer. Not live traffic.
Advisor
Tuning is count → promote. Rules start in count. After 24 hours, the Advisor names what's safe — you click once. Nothing auto-blocks. It never flips a rule to block on its own. Rule-based checks on this site's logs — the same evidence always gives the same answer.
21 hours left in the 24-hour count window.
Count window
Each managed rule in count is on this track. Counted hits and site requests are the shared 24-hour CloudWatch rollup, so they match Analytics and the Advisor. A missing series says not confirmed, not zero.
- StartRules enter count
- 12hseries
- 24hdecision
- 7dyour click
- Site requests in 24h: not confirmed
- CloudWatch series: not confirmed
- In count for 3 hours, since this site was protected
First 24 hours. Managed rules stay in count. The Advisor will not say Promote until that 24-hour watch window closes, and only when the decision table's evidence is complete. If CloudWatch has not published the series, this timeline says not confirmed. That is not zero traffic, and it is not a reason to block.
First 7 days. Promote still uses the latest 24-hour rollup — the same CloudWatch numbers as Analytics and the Advisor. A full week in count does not flip a rule to block. On day 7 you still click Promote, and only for a rule whose evidence is complete.
- SQL injectionIn count for 3 hours, since this site was protected
- Counted hits in 24h: not confirmed
Before Promote- A closed 24-hour watch window. The Advisor does not say Promote while the clock is open.
What would change this. needs about 21 more hours of data
What happens next. Keep this rule in count. When the 24-hour window closes, the Advisor reads the decision table again. It says Promote only if the evidence is complete. You still click.
- Linux server exploitsIn count for 3 hours, since this site was protected
- Counted hits in 24h: not confirmed
Before Promote- A closed 24-hour watch window. The Advisor does not say Promote while the clock is open.
What would change this. needs about 21 more hours of data
What happens next. Keep this rule in count. When the 24-hour window closes, the Advisor reads the decision table again. It says Promote only if the evidence is complete. You still click.
Rule-based notes from this count window. You still click once.
Next: check back when the window closes. Nothing blocks until you click Promote.
- PromoteQuiet in the window — safe to start blocking after you click.
- HoldStill watching or noisy — keep counting.
- Needs allowlistLooks like real visitors — allow that traffic first.
- SQL injectionHold
Still inside the 24-hour count window (21h left) for SQL injection (sql_injection).
No counted hits yet. Wait until the window closes, then re-check — especially if you expect LMS, registration POSTs, monitoring, CMS, or SSO paths in this traffic. Nothing blocks until you click.
Blocking. This rule has been in count for 3 hours, short of the 24-hour watch window. The Advisor does not say Promote while that clock is open. This rule counted 0 hits.
What would clear this. The 24-hour watch window has to close. After that, the rest of the table runs. A quiet rule on a site with enough traffic can say Promote. A known-good form can say Needs allowlist. Anything else stays Hold. Attack samples during the open window do not skip it. Closing the window is not itself Promote.
Next look. About 21 more hours left in the watch window. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. This clears on its own when that time passes. Nothing you click skips the clock.
Evidence- 24h window
- Counted not confirmed
- Linux server exploitsHold
Still inside the 24-hour count window (21h left) for Linux server exploits (linux_exploits).
No counted hits yet. Wait until the window closes, then re-check — especially if you expect LMS, registration POSTs, monitoring, CMS, or SSO paths in this traffic. Nothing blocks until you click.
Blocking. This rule has been in count for 3 hours, short of the 24-hour watch window. The Advisor does not say Promote while that clock is open. This rule counted 0 hits.
What would clear this. The 24-hour watch window has to close. After that, the rest of the table runs. A quiet rule on a site with enough traffic can say Promote. A known-good form can say Needs allowlist. Anything else stays Hold. Attack samples during the open window do not skip it. Closing the window is not itself Promote.
Next look. About 21 more hours left in the watch window. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. This clears on its own when that time passes. Nothing you click skips the clock.
Evidence- 24h window
- Counted not confirmed
Example series: five quiet hours, then 80 counted requests. Still example data.
Example dataExample series: five quiet hours, then 80 counted requests. Still example data.
Advisor
Tuning is count → promote. Rules start in count. After 24 hours, the Advisor names what's safe — you click once. Nothing auto-blocks. It never flips a rule to block on its own. Rule-based checks on this site's logs — the same evidence always gives the same answer.
Nothing is ready to promote yet — 3 on hold. Windows exploits (windows_exploits) jumped in the last hour — 80 counted hit(s) on GET /about.
Count window
Each managed rule in count is on this track. Counted hits and site requests are the shared 24-hour CloudWatch rollup, so they match Analytics and the Advisor. A missing series says not confirmed, not zero.
- StartRules enter count
- 12hseries
- 24hdecision
- 7dyour click
- Site requests in 24h: 4,000
- CloudWatch series: 24 hours
- In count for 2 days, since this site was protected
- Windows exploitsIn count for 2 days, since this site was protected
- Counted hits in 24h: 80
Before Promote- A known-good form, or a clear attack with a count under 50. The last hour jumped — at least 50 counted requests, and at least 3× the earlier hours. 50 or more hits stay on Hold even when every sample is an attack.
What would change this. a known-good form can ask for an allowlist; a last-hour jump of 50 or more stays on hold even when the samples are attacks
What happens next. Keep this rule in count. A counted jump is not a reason to Promote. A known-good form can ask for an allowlist. An explained attack at this size stays on Hold.
- PHP exploitsIn count for 2 days, since this site was protected
- Counted hits in 24h: 50
Before Promote- A known-good form, which asks for an allowlist, or a count under 50 whose samples are an explained attack. 50 or more hits stay on Hold even when every sample is an attack.
What would change this. a known-good form can ask for an allowlist; 50 or more hits stay on hold even when the samples are attacks
What happens next. Hold this rule and review the events. A clear attack at this size stays on Hold. Nothing blocks until you click.
- Application DDoS protectionIn count for 2 days, since this site was protected
- Counted hits in 24h: 8
Before Promote- Nothing to collect. Rate limits stay in count even after an allowlist.
What would change this. the allowlist is saved; a rate limit stays in count
What happens next. Leave this rule in count. The Advisor will not say Promote.
Rule-based notes from this count window. You still click once.
3 on hold.
- PromoteQuiet in the window — safe to start blocking after you click.
- HoldStill watching or noisy — keep counting.
- Needs allowlistLooks like real visitors — allow that traffic first.
- Windows exploitsHold
Low confidence to promote — review the evidence first. You still click once.
Windows exploits (windows_exploits) jumped in the last hour — 80 counted hit(s) on GET /about.
Those paths are not clearly attacks, so a counted jump is not a reason to promote. Keep it in count until you recognize the traffic. You stay in control — nothing blocks until you click.
Blocking. The sampled path is not a known-good form and not a clear attack, and the last hour jumped: at least 50 counted requests, and at least 3 times the earlier hours. This rule counted 80 hits.
What would clear this. A known-good form on a later look becomes Needs allowlist. A jump that meets this floor is at least 50 hits, so an explained attack at that size stays Hold. The jump is not a reason to Promote.
Next look. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. Investigate one matching request. That asks a person to look at that request. It does not promote this rule, and it does not change this Hold.
Evidence- 24h window
- Counted 80
- GET /about
Top paths in the sample- 4GET /about
Sample rows only. Counted 80 is the full 24h window.
Sample requests- GET /about · 203.0.113.xx
- PHP exploitsHold
Low confidence to promote — review the evidence first. You still click once.
PHP exploits (php_exploits) counted 50 hit(s) on GET /news in the 24-hour window.
That is at least 50 hits, and the path is not a known-good form or a clear attack, so this is not safe to block yet. Keep it in count and review the events. You stay in control — nothing flips to block on its own.
Blocking. The path is not a known-good form and not a clear attack. The count is at least 50. This rule counted 50 hits.
What would clear this. A known-good form becomes Needs allowlist. Promote on a later look needs every sample to be an attack, the count under 50, and the count at most 8 times the sample rows. 50 or more hits stay Hold even when every sample is an attack.
Next look. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. Investigate one matching request. That asks a person to look at that request. It does not promote this rule, and it does not change this Hold.
Evidence- 24h window
- Counted 50
- GET /news
Top paths in the sample- 2GET /news
Sample rows only. Counted 50 is the full 24h window.
Sample requests- GET /news · 203.0.113.xx
- Application DDoS protectionHold
Low confidence to promote — review the evidence first. You still click once.
Allowlist covers POST /api/v1/orders.
This is a rate limit, so it stays in count. You stay in control — nothing blocks until you click.
Blocking. The allowlist is already saved. This is still a rate limit, so it stays in count.
What would clear this. A rate limit does not become Promote or Needs allowlist after an allowlist. The allowlist stays saved.
Next look. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. Nothing on this page turns this into Promote. Leave the rule in count.
Evidence- 24h window
- Counted 8
- POST /api/v1/orders
Top paths in the sample- 2POST /api/v1/orders
Sample rows only. Counted 8 is the full 24h window.
Sample requests- POST /api/v1/orders · 192.0.2.xx · API
False-positive risk: API.
Rate-limit rule. Blocking starts when a client crosses the threshold, including shared networks.
Allowlist savedManaged rules stay in count until you promote. Remove puts this path back under them.
Example of POST /login already allowlisted while the 24-hour clock is still open. Still example data.
Example dataExample of POST /login already allowlisted while the 24-hour clock is still open. Still example data.
Advisor
Tuning is count → promote. Rules start in count. After 24 hours, the Advisor names what's safe — you click once. Nothing auto-blocks. It never flips a rule to block on its own. Rule-based checks on this site's logs — the same evidence always gives the same answer.
21 hours left in the 24-hour count window.
Count window
Each managed rule in count is on this track. Counted hits and site requests are the shared 24-hour CloudWatch rollup, so they match Analytics and the Advisor. A missing series says not confirmed, not zero.
- StartRules enter count
- 12hseries
- 24hdecision
- 7dyour click
- Site requests in 24h: 4,000
- CloudWatch series: 3 hours
- In count for 3 hours, since this site was protected
First 24 hours. Managed rules stay in count. The Advisor will not say Promote until that 24-hour watch window closes, and only when the decision table's evidence is complete. If CloudWatch has not published the series, this timeline says not confirmed. That is not zero traffic, and it is not a reason to block.
First 7 days. Promote still uses the latest 24-hour rollup — the same CloudWatch numbers as Analytics and the Advisor. A full week in count does not flip a rule to block. On day 7 you still click Promote, and only for a rule whose evidence is complete.
- WordPress protectionIn count for 3 hours, since this site was protected
- Counted hits in 24h: 6
Before Promote- A closed 24-hour watch window. An allowlist does not skip the clock.
What would change this. the allowlist is saved; needs about 21 more hours of data
What happens next. Keep this rule in count until the window closes. The Advisor reads the decision table again after that. You still click.
Rule-based notes from this count window. You still click once.
Next: check back when the window closes. Nothing blocks until you click Promote.
- PromoteQuiet in the window — safe to start blocking after you click.
- HoldStill watching or noisy — keep counting.
- Needs allowlistLooks like real visitors — allow that traffic first.
- WordPress protectionHold
Allowlist covers POST /login.
The 24-hour window is still open, so this stays on hold. You stay in control — nothing blocks until you click.
Blocking. The allowlist is already saved. The 24-hour watch window is still open, and the allowlist does not skip that clock.
What would clear this. The watch window has to close. The saved allowlist stays. After that, the rest of the table runs. A quiet rule on a site with enough traffic can say Promote. A known-good form can say Needs allowlist. Anything else stays Hold.
Next look. The allowlist is saved. About 21 more hours left in the watch window. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. This clears on its own when that time passes. Nothing you click skips the clock.
Evidence- 24h window
- Counted 6
- POST /login
Top paths in the sample- 2POST /login
Sample rows only. Counted 6 is the full 24h window.
Sample requests- POST /login · 192.0.2.xx · login
False-positive risk: login.
Allowlist savedManaged rules stay in count until you promote. Remove puts this path back under them.
Example of 12 site requests with GET /healthz already allowlisted. Still example data.
Example dataExample of 12 site requests with GET /healthz already allowlisted. Still example data.
Advisor
Tuning is count → promote. Rules start in count. After 24 hours, the Advisor names what's safe — you click once. Nothing auto-blocks. It never flips a rule to block on its own. Rule-based checks on this site's logs — the same evidence always gives the same answer.
Nothing is ready to promote yet — 1 on hold. Allowlist covers GET /healthz.
Count window
Each managed rule in count is on this track. Counted hits and site requests are the shared 24-hour CloudWatch rollup, so they match Analytics and the Advisor. A missing series says not confirmed, not zero.
- StartRules enter count
- 12hseries
- 24hdecision
- 7dyour click
- Site requests in 24h: 12
- CloudWatch series: 24 hours
- In count for 2 days, since this site was protected
- Anonymous IP listIn count for 2 days, since this site was protected
- Counted hits in 24h: 2
Before Promote- At least 50 site requests. The allowlist does not skip the low-traffic hold.
What would change this. the allowlist is saved; needs about 38 more site requests
What happens next. Keep counting. The Advisor will not say Promote until the site has real traffic. You still click later.
Rule-based notes from this count window. You still click once.
1 on hold.
- PromoteQuiet in the window — safe to start blocking after you click.
- HoldStill watching or noisy — keep counting.
- Needs allowlistLooks like real visitors — allow that traffic first.
- Anonymous IP listHold
Low confidence to promote — review the evidence first. You still click once.
Allowlist covers GET /healthz.
Traffic is still too low to promote. You stay in control — nothing blocks until you click.
Blocking. The allowlist is already saved. The site is still under 50 requests, and the allowlist does not skip that hold.
What would clear this. The site needs at least 50 requests. The saved allowlist stays. After that, the rest of the table runs. A quiet rule on a site with enough traffic can say Promote. A known-good form can say Needs allowlist. Anything else stays Hold.
Next look. The allowlist is saved. About 38 more site requests would reach 50. The Advisor reads this again when you open Tuning, and on the check that runs about every 15 minutes. That look does not promote the rule.
Next step. This clears only when more traffic shows up. Investigating a sample does not skip it.
Evidence- 24h window
- Counted 2
- GET /healthz
Top paths in the sample- 1GET /healthz
Sample rows only. Counted 2 is the full 24h window.
Sample requests- GET /healthz · 203.0.113.xx · monitoring
False-positive risk: monitoring.
Low traffic: 12 requests in this window — not enough to treat a quiet rule as safe.
Allowlist savedManaged rules stay in count until you promote. Remove puts this path back under them.
Rate limits that fit the site
The same example site, judged from its request log. Login can Promote. Checkout does not have enough traffic, so it stays on Hold. The API would limit a webhook, so it Needs allowlist. The buttons do not change a rule.
Rate limits that fit this site
Normal and peak are requests from one address in 5 minutes, the same window AWS WAF uses for a rate-based rule. A fitted limit starts in count. You click Promote. Count does not block.
- All traffic rate limitNeeds allowlist
Normal: 2 requests per IP per 5 minutes · Peak: 40 requests per IP per 5 minutes
Normal is 2 requests per IP per 5 minutes. Peak is 40 requests per IP per 5 minutes. 5 distinct addresses would have been limited at 10 requests per IP per 5 minutes. 1 looks like a webhook, 4 look like attack tools. Add that bot, webhook, or monitor under Always allow before Promote. Do not allowlist the path. A path allowlist does not turn this rate limit off. Nothing blocks until you click Promote.
What would change this: add the known-good bot, webhook, or monitor to Always allow. Do not allowlist the path — a path allowlist does not turn this rate limit off
- Login rate limitPromote
Normal: 3 requests per IP per 5 minutes · Peak: 40 requests per IP per 5 minutes
Normal is 3 requests per IP per 5 minutes. Peak is 40 requests per IP per 5 minutes. 4 distinct addresses would have been limited at 10 requests per IP per 5 minutes. 4 look like attack tools. Nothing blocks until you click Promote.
Installed in count at 10 per 5 minutes.
- Checkout rate limitHold
Normal: not confirmed · Peak: not confirmed
Not enough traffic to judge checkout. 3 requests from 2 distinct addresses. This stays on hold. Normal and peak are not confirmed. Nothing was promoted.
What would change this: needs at least 20 requests on this path, at least 5 distinct addresses
- xmlrpc.php rate limitHold
Normal: not confirmed · Peak: not confirmed
No xmlrpc.php requests in this window, so this rate is not confirmed. Normal and peak are not confirmed. Nothing was promoted.
What would change this: needs request logs that include this path
- API rate limitNeeds allowlist
Normal: 2 requests per IP per 5 minutes · Peak: 30 requests per IP per 5 minutes
Normal is 2 requests per IP per 5 minutes. Peak is 30 requests per IP per 5 minutes. 1 distinct address would have been limited at 10 requests per IP per 5 minutes. 1 looks like a webhook. Add that bot, webhook, or monitor under Always allow before Promote. Do not allowlist the path. A path allowlist does not turn this rate limit off. Nothing blocks until you click Promote.
What would change this: add the known-good bot, webhook, or monitor to Always allow. Do not allowlist the path — a path allowlist does not turn this rate limit off
When something is happening right now
The same example site, during a login flood. The Advisor says Promote on a two-hour login rate limit, and Hold on checkout. A probe block is already on, with time left. The buttons do not change a rule.
Right now
The last 15 minutes compared with this site's previous day. A response stays up for 2 hours, then comes off. Always-allow addresses, verified crawlers, checkout, and webhook clients are not the target. Nothing is applied until you click.
Rate limit login for 2 hours
- Rate limit login for 2 hoursPromote
Login is hotter than usual. 240 requests in 15 minutes, versus about 4 in a typical 15 minutes on the previous day. The temporary limit is 20 requests per address per 5 minutes. Always-allow addresses, verified crawlers, and webhook clients are left out. 90% of these requests are from ZZ, versus 1% of the previous day.
- Checkout or webhook surgeHold
80 requests in 15 minutes, versus about 3 in a typical 15 minutes on the previous day. Part of this surge is checkout or payment traffic.
What would change this: Do not rate-limit or block checkout. A sale and an attack can share that path, so this stays on Hold.
- Temporary block of 2 addresses1 hour 12 minutes left
Two addresses requested /.env, /.git, and wp-config.php. Example only.
This is on until the countdown ends.
Questions
Is this a real customer?
No. This page is example data: an invented site, invented counts, and masked sample IPs. It is not a customer and not live traffic.
Does WAF Cybersecurity Advisor block traffic on its own?
No. It recommends Promote, Hold, or Needs allowlist and explains why. You still click Promote. It never flips a rule to block on its own.
What is the Needs allowlist draft on this example?
The example shows POST /saml/acs, an SSO path, as the exact path to allow before that rule is promoted. The Advisor does not write the allowlist. You still decide.
What is the Virtual patch available card?
It names a known exploit class, the managed rule group that watches that class, and whether the group is already on in count or block. Add in count mode is a click, and only when the group is off. With no signal on the site, the card is a general advisory. On this page the button is an example and does not save a rule.
What does the New protection label mean?
A new AWS rule group version, or a named threat for a stack already on the site, lands in count. The label says why. The Advisor uses the same Promote, Hold, or Needs allowlist verdict. You still click Promote. Nothing blocks until you do.
Why is the remembered example on Hold?
A fictional owner undid Linux server exploits on Sept 30, 2026 after checkout callbacks on POST /wc-api/WC_Gateway_Paypal were blocked. The Advisor holds that rule and says what new evidence would clear the lesson. The clear button is an example and does not change a rule. You still click Promote on a real site.
See it on your site
Rules start in count. After 24 hours, your dashboard shows what's safe to block — one click.
Start a 14-day trialCard at Stripe checkout. Cancel before the 14-day trial ends and you won't be charged.
$150/site/mo after the trial
What is the WAF Cybersecurity Advisor? · How count mode works · What's safe to block · Pricing