Use this worksheet with each provider you are considering. Agree on expected results before testing. Run controlled tests on systems you manage, using test accounts and sample data. Start in staging and agree on a small production scope with the application owner.
Set the scope
Record the service and plan, application, routes, client types, current CDN, proposed request path, test dates and people involved. Name one person who can stop the trial. Save the current rules and routing settings before making changes.
On small screens, scroll each table sideways to read all columns. For each row, copy the input and expected action into your test record. Add the actual result, time, policy version, reviewer and follow-up. Replace each owner role with a person's name. Mark an unavailable field as unavailable and agree on another way to check the result.
Understand the fields
Request from each provider: The record fields below are a buyer's checklist. Ask for the actual field names, sample records, plan access, retention, sampling and export options. Ask the provider to mark unavailable fields and explain their effect on the trial.
Described in Peakhour content: Peakhour's bot management content describes allow, challenge, rate limit, block and log actions with request context. Its rate-limiting documentation lists paths, headers, ASN, country, IP, TLS fingerprints, response codes, thresholds and intervals. Its log-forwarding content describes bot classification and cache state in enriched request logs. Confirm the available field names and values for your deployment during the trial.
Task completion, owner names, test labels, expected results, quote totals and rollback timing are records your team keeps. Ask separately about per-tool AI crawler views, mobile coverage, matched rule IDs, request IDs and links between edge and origin logs.
Check clients and bot policy
| Test input | Expected action to agree | Fields to record or request | Owner |
|---|---|---|---|
| Approved search crawler visiting a public page, with its identity checked | Allow the approved crawler within the agreed limits | Crawler name, identity check, path, policy, action and response status | SEO lead |
| Approved AI crawler and user-driven AI retrieval request on agreed public routes | Apply the allow or rate policy chosen for each crawler purpose | Tool name if available, purpose, path, policy, action and request count | Content owner |
| Unapproved scraper requesting a controlled set of test pages | Apply the agreed block, challenge or rate action | Test label, path, request rate, action and response status | Security lead |
| Browser login, search, cart and checkout using test accounts | Complete valid tasks under the agreed policy | Browser version, task result, action, status and any challenge result | Web application owner |
| Valid API call, partner callback and token refresh using test credentials | Return the expected API response under the agreed policy | Method, path, client type, status, policy and action; keep tokens out of the record | API owner |
| Supported mobile app performing login, token refresh and an API task | Complete the task with the response the app can handle | App and OS version, task result, status, action and any required SDK setup | Mobile lead |
| Valid upload or form value that previously triggered a rule | Allow the valid request after review of a narrow exception | Matched rule if available, exception scope, action, status and task result | WAF operator |
| Known valid requests reviewed across all client tests | Meet the false-block and task-completion limits agreed before the trial | Valid requests tested, valid requests blocked or challenged, failed tasks and review notes | QA lead |
Count a false block only after the application owner confirms the request was valid. Record challenges separately. Include scheduled jobs and less frequent workflows in the test period.
Check the CDN path and enforcement
| Test input | Expected action to agree | Fields to record or request | Owner |
|---|---|---|---|
| Repeat a permitted cacheable request until it is a cache hit | Serve the expected content and apply the controls assigned to this path | Cache state, enforcing layer, action, response status and origin receipt if any | CDN operator |
| Request an uncached test object or use an approved cache purge | Fetch the expected content through the agreed security path | Cache state, action, status and matching origin record if available | CDN operator |
| Send a controlled blocked request to both cached and uncached routes | Enforce the agreed action at the intended layer | Cache state, enforcing layer, rule or policy, action and origin receipt if any | Security lead |
| Send a request through the trusted CDN, then repeat with a forged client-IP header | Preserve the verified client IP and remove or replace the forged value at the trusted boundary | Test source IP, received client IP, forwarding header, trusted proxy and capture point | Network owner |
| Increase test requests just below and above the chosen rate threshold | Allow requests below the threshold and apply the chosen action above it | Rate key, threshold, interval, counter if available, action and response status | Rate-rule operator |
| Run two valid clients sharing an IP alongside a controlled high-rate client | Keep valid tasks within agreed limits while enforcing the intended rule | Client test labels, shared IP, rate key, action and task results | API owner |
| Follow one allowed and one blocked request through the logging route | Find records that explain the decision and reach the chosen destination | Time, request ID if available, method, path, client IP, policy, matched rule, action, status and export delay | Logging owner |
Document where each service sees a request. A cache hit may end at the CDN before a downstream service receives it. Test both cache states and identify which layer enforces each rule. Record where client IPs and fingerprints are captured, since a connection from a CDN can describe the CDN itself.
Assign operations and rollback
| Test input | Expected action to agree | Fields to record or request | Owner |
|---|---|---|---|
| Apply one reviewed policy change within the trial scope | Named operator applies it and a second person reviews the result | Operator, reviewer, policy version, change time and affected routes | Security lead |
| A valid task fails after a controlled rule change | Stop expansion, inspect the request and restore the agreed policy if needed | Failure time, task, action, decision owner and recovery result | Application owner |
| Rehearse restoring saved rules and the previous traffic path | Restore the approved setup within the agreed recovery time | Restore steps, DNS or routing settings, cache effects, elapsed time and task checks | Release owner |
| Raise an agreed trial support question | Reach the contracted support channel and confirm escalation steps | Plan, hours and time zone, contact, response commitment and ticket reference | Service owner |
Set stop conditions before production testing. Examples include a failed payment callback, a valid login blocked or missing logs on a route that requires review. Name who can restore rules, routing, DNS and TLS settings. Test rollback access before the trial starts.
Compare pricing on the same scope
| Test input | Expected action to agree | Fields to record or request | Owner |
|---|---|---|---|
| The same monthly request, bandwidth and peak-rate estimate for each provider | Provider returns a quote for the agreed traffic scope | Requests, bandwidth, peak rate, regions, sites, currency, tax and quote date | Finance owner |
| Separate counts for allowed, blocked, challenged, cache-hit and cache-miss requests | Provider explains which counts affect billing | Billing unit, included volume, exclusions, overage rate and spending alerts | Finance owner |
| List of required bot, WAF, rate, API, log and deployment controls | Quote identifies included features and each required add-on | Plan, add-ons, rule limits, log retention, export charges and setup fees | Procurement owner |
| Normal traffic, a seasonal peak and an agreed attack-volume scenario | Provider explains the bill and any usage limits for each scenario | Scenario volume, assumptions, overages, minimum spend and term | Finance owner |
| Required support and ongoing rule-management tasks | Quote names the support and operating responsibilities | Support hours, escalation, managed-service scope, fees, renewal and exit terms | Service owner |
Review the result together
Have the application, security, CDN and finance owners review the completed rows. List failed tests, missing fields, open costs and the person resolving each item. Agree on the next scope only after reviewing task results and rollback readiness.
Return to the provider comparison hub to choose the guides relevant to your setup.