Prove that origin work changed before touching the cache
Start with one quiet 15-minute window before the cache-rule release and one equally quiet window after it. Export Cloudflare requests, origin access logs, WordPress AI attempts, provider request IDs, and provider token usage in UTC. Flat page views plus higher origin requests is only a symptom; the joined request trail is the evidence.
Choose a single URL and reproduce it twice with the same method, query string, cookies, and Accept headers. The control request must show a cache hit, while the suspect request must reach origin. If those conditions cannot be reproduced, pause the change review and investigate traffic mix rather than inventing a cache explanation.
Capture the two paths at the edge
For each request, save the full URL, method, response status, CF-Cache-Status, Age, Cache-Control, Vary, Set-Cookie, and a request or trace identifier. Also record which cache rule matched. A screenshot of an aggregate hit-rate chart cannot reveal whether a cookie, query parameter, or bypass expression owned the divergence.
Compare the effective cache key, not just the visible URL. A newly included query parameter, cookie, device header, or language header can turn one apparent page into many cache objects. Conversely, a bypass rule can send every variant to origin even though the key itself is unchanged.
Join edge, WordPress, and provider evidence
At origin, locate both requests by timestamp and request ID. Record the WordPress route or hook, whether the AI integration executed, its attempt ID, response code, duration, and estimated tokens. Then join the provider request ID and billed token count; do not infer paid work from an origin HTTP 200 alone.
If Cloudflare shows a miss but WordPress does not execute AI work, the incident is a cache-efficiency issue rather than an AI-cost issue. If WordPress executes but no provider record exists, inspect queueing and local failures. If all three records join, the request path has proven financial consequence.
| Evidence | Cached control | Origin suspect | Decision use |
|---|---|---|---|
| CF-Cache-Status / Age | HIT / positive | BYPASS or MISS / absent | Confirms edge divergence |
| Matched cache rule | Expected rule | Different rule or no match | Names the change owner |
| Origin request ID | Absent | Present | Proves origin arrival |
| Provider request ID and tokens | Absent | Present with usage | Proves paid work |
Change only the owner of the divergence
Roll back or narrow the single rule that explains the two paths. Preserve security and personalization exclusions: never force-cache authenticated, cart, checkout, or user-specific responses merely to recover a hit ratio. The safe repair may be removing one unnecessary header from the cache key rather than caching the whole route.
Repeat the paired requests after the change and keep all other inputs fixed. Acceptance requires the intended public response to hit cache, no unintended personalized response to be cached, and no origin or provider event for the control path. A recovered aggregate hit ratio alone is insufficient.
Close with a reusable evidence map
Store the four-row evidence map with the rule ID, deploy time, test commands, UTC timestamps, and approver. Add the 15-minute before-and-after counts for edge hits, origin arrivals, WordPress attempts, and provider tokens so a later invoice review can reproduce the conclusion.
The incident is closed when the divergent rule is identified, the two-request test passes, personalization remains protected, and the next provider-usage window shows the expected reduction. Use the implementation guide to turn those checks into a standing release test rather than relying on memory.
Use the edge-to-origin evidence map from “Cloudflare cache hits disappeared: trace the AI request that moved to origin” on a real first installation. Download AI Cost Circuit Breaker for free, begin in Monitoring, and move to enforcement only after the expected signals and rollback are verified.