Hints reference
Every hint the Performance dashboard can raise: what triggers it, what it means, and what to do about it.
#Hints reference
The Performance dashboard raises hints when your traffic matches a known expensive pattern. Each hint shows the evidence that triggered it (the actual numbers, over the selected time range) and links to the fix. The top three appear on the dashboard landing view; the rest appear as chips on group rows and in the endpoint detail view.
This page lists every hint the dashboard can raise.
#index-scan
Trigger: read amplification above 25× on a collection's list or filter traffic.
Queries on this collection read far more rows than they return, which almost always means a filter or sort is scanning the table instead of using an index. This is the most common and most fixable cost problem — an index on the filtered field typically cuts amplification to near 1×.
What to do: follow index tuning — identify the filtered field from the evidence, index it, verify with a receipt.
#n-plus-one
Trigger: average D1 queries per request above 8 on one endpoint group.
Requests to this endpoint run an unusually high number of queries. Several queries per request is normal (auth and permission checks account for a fixed handful), but a high average usually means something queries per record — most often relation expansion fetching related records one at a time instead of in a batch.
What to do: check whether the endpoint expands relations over large result sets. Reducing the page size, or restructuring the call to fetch related records in one filtered query (_in on the collected IDs), removes the per-record multiplier. See filtering for batch query patterns.
#unpaginated
Trigger: average rows returned above 500 on a list endpoint.
List queries on this endpoint return very large result sets. Beyond the transfer cost, every returned row is also a row read — and clients rarely use more than a page.
What to do: add a limit to the client's list calls (default page size is 25) and paginate with page or a cursor. See pagination with filters.
#kv-heavy
Trigger: KV reads per day above 60% of the free-tier cap.
Session lookups make one KV read per authenticated request, so KV reads track your total traffic. This hint fires while there's still headroom, because the fix is architectural rather than a quick tune.
What to do: this is a traffic-volume signal, not a bug. Check the KV gauge's projection — if growth is steady, plan for the paid tier or reduce authenticated request volume (client-side caching of stable reads is the usual lever). See Cloudflare costs for the limits involved.
#tier-projection
Trigger: any free-tier gauge projected to hit its cap within 30 days at the current growth rate.
One of your resource gauges — rows read, rows written, requests, KV reads, or DO requests — is on course to hit its daily limit. The hint names the resource and the projected date.
What to do: open the Performance tab pre-filtered to that resource's groups view and find the biggest consumer. If it's a fixable pattern, another hint (index-scan, unpaginated) usually accompanies this one. If consumption is legitimate growth, budget for the paid tier before the cap does it for you — free-tier overruns fail requests rather than billing you.
#analytics-volume
Trigger: analytics writes approaching the data points included with your plan each month.
EmuView writes one analytics datapoint per request — every request, with no application-level sampling. Workers Paid includes 10 million data points a month; beyond that they bill per additional million written.
What to do: nothing, usually. This hint is a heads-up, not a fault: it means a line will start appearing on your Cloudflare bill, not that anything is being dropped or degraded.
There is deliberately no setting to sample these writes down. The access log and the usage ledger both depend on the stream being complete, and a datapoint costs the same whatever it carries, so recording less would trade something you need for a saving measured in cents. Cloudflare applies its own adaptive sampling under extreme load; the dashboard corrects for that automatically and tells you when a figure came from a sampled window.