Need to monitor when a single WAF rule triggers too much. Goal: alert if any rule blocks >100 requests in 60 seconds.
Use Cloudflare GraphQL API with a cron job. Steps:
1. Create API token with "Account Analytics" read permission.
2. Set up query to fetch `httpRequests1mGroups` filtered by `action` equals `block`. Group by `ruleId`.
3. Sum the `count` for each rule over the last minute.
4. Trigger alert (email, webhook, PagerDuty) if any sum exceeds 100.
Example GraphQL query body:
```json
{
"query": "query GetBlockedRequests($accountTag: string, $datetimeStart: string, $datetimeEnd: string) { viewer { accounts(filter: {accountTag: $accountTag}) { httpRequests1mGroups(limit: 100, filter: {datetime_geq: $datetimeStart, datetime_leq: $datetimeEnd, action: "block"}) { sum { count } dimensions { ruleId } } } } }",
"variables": {
"accountTag": "YOUR_ACCOUNT_ID",
"datetimeStart": "2024-01-01T10:00:00Z",
"datetimeEnd": "2024-01-01T10:01:00Z"
}
}
```
Run this every minute. Parse response, check each `sum.count`. Alerting logic depends on your stack (e.g., Python script with requests library, checks results, sends to Slack).
Pitfalls:
* RuleID might be empty string for non-rule blocks.
* GraphQL latency ~1-2 minutes for data availability.
* Manage API token secrets securely in your cron environment.
- bench_beast
Benchmarks don't lie.
That's a solid approach for anyone comfortable with scripting and managing their own cron infrastructure. One detail I'd add is about handling the ruleId dimension when it's null, which happens for blocks not tied to a specific WAF rule, like a generic IP firewall block. Your script's sum check will still work, but you'll want to filter those out before counting or label them distinctly in the alert, otherwise you might get noisy alerts for "Rule: null".
Also, while the cron-every-minute method works, watch out for slight API latency. The data for the most recent minute might not be fully complete for a minute or two after the period ends. Some folks add a three-minute delay to their query (e.g., query for 10:00-10:01 at 10:04) to avoid false lows, but that depends on how real-time you need the alert to be.
The right tool saves a thousand meetings.
That's a helpful example query. How does this compare to using the newer GraphQL Analytics API endpoints vs the older ones? I've heard there are some differences in available fields and latency.
Also, for the alerting logic itself, are you handling deduplication? If a rule breaches 100 for multiple minutes, you might get a flood of alerts. A simple cooldown in your script might be needed.