On this page
Your activity view shows hundreds of crawler requests, while your account has used far fewer fresh renders. That difference can be expected: a request is an observed event, while fresh-render allowance measures eligible rendering consumption under the account's usage rules.
A cached response can serve a request without using another fresh render. Failed requests and other delivery paths also need their own interpretation. Compare the definitions and time windows before treating the totals as a billing error.
Identify the unit behind each number
Crawler activity describes recorded requests in the selected view. Fresh-render usage describes account consumption in the applicable allowance period. A cache-hit count describes a subset of recorded delivery events.
None of those counts measures human visitors, unique people or AI answers. A crawler request can be recorded without establishing that the content was indexed, cited or used in training.
Write down the exact label, site or workspace scope, period and observation time for each number. Similar labels are not enough to establish that the same events are being counted.
Separate cached delivery from new rendering
A successful cache hit can return previously rendered content. It is useful activity, but it does not consume another fresh-render allowance unit in PB's reviewed usage model.
A cache miss is different from a cache hit, but the label alone still does not prove a completed billable render. Check the operation's outcome and the account's applicable usage rules. Failures, reservations and other request paths may need reconciliation with the usage record.
Do not calculate expected billing simply by subtracting cache hits from all requests. That shortcut assumes every remaining request becomes one charged fresh render, which has not been established.
Work through a request ledger
Illustrative example only. These are invented diagnostic counts, not an account invoice or a universal billing formula.
A site has 120 recorded requests in a defined observation window:
| Recorded category | Requests | What to review |
|---|---|---|
| Cache hits | 90 | Served from cache; not new fresh-render consumption |
| Successful cache misses | 20 | Check corresponding eligible render operations |
| Failed requests | 5 | Inspect outcome and settlement rules |
| Other or unresolved delivery states | 5 | Establish the actual delivery path |
| Total | 120 | Keep the same site and window throughout |
The table explains why 120 requests should not automatically mean 120 fresh renders. It does not establish an exact charge of twenty renders. That requires the effective account period and operation evidence.
If the account usage says a different number, preserve both values and investigate the remaining difference instead of forcing the request table to match.
Align the period and population
An activity chart covering the last thirty days is not necessarily aligned with the current billing period. A site-specific filter is not necessarily aligned with a workspace allowance shared across sites.
Check whether the view uses a full aggregate or a bounded sample of recent requests. A filter can change the available population. Missing site data or unavailable records should remain visible as coverage limits.
Record the exact period boundaries and time zone where available. “This month” and “last thirty days” can include different events even when checked on the same date.
Treat Fresh labels carefully
Fresh-related labels need the context of the specific card, chart or row. Confirm whether the label describes a response state, a completed render or another classification before comparing it with account usage.
A cached response is not evidence of another render, and a delivery label does not prove that the content was compared with the latest CMS version. Views can also use different periods or populations.
Use the actual response and cache evidence for delivery questions, and the effective usage record for allowance questions. If the interface wording is unclear, ask for the definition behind the specific view.
Build a focused support packet
Provide the account or workspace reference through the normal private support channel, the metric labels, redacted screenshots, observation time, period boundaries and selected filters. Include relevant operation references when available, without credentials or unnecessary page content.
State the expected difference explicitly: “The account shows this usage for these dates, while this site view shows these events.” That gives support a concrete comparison.
A trial, legacy plan or active add-on can affect the effective allowance. Confirm the account's actual entitlement rather than inferring it from a public plan name. Do not purchase capacity or alter records merely to make the displayed numbers agree.
Close the reconciliation with an explanation
The result should identify either an expected difference in scope or a specific issue requiring correction: a display mismatch, entitlement mapping, missing operation settlement or period boundary.
After any authorized correction, compare the same metrics and dates again. Keep the explanation with the case so the next report does not repeat the same confusion.
Prerender Buddy's activity evidence helps explain what requests were recorded. Its account usage explains consumed allowance. Both are useful when the question and counting unit stay attached to the number.