Robinhoodunder the lens.
Where eth_getLogs actually stops.
Observed limits. Verbatim evidence (private addresses redacted).
4663 / RH
01 /Where each query actually stops
Span in blocks · logarithmic scaleLoading measurements…
02 /Evidence, not assumptions.
Raw APIThe provider's own words, grouped by refusal type. Our configuration mistakes and self-limited reads are disclosed separately, never counted as provider failures.
Counts, not synthetic telemetry.+Decode an error
Classified by the prober's own classifierWe classify the text you paste. Remove keys and URLs first; we strip anything that looks like one, but don't rely on that.
03 /Know what you're looking at.
API documentationA limit is a bracket.
Not a promise.
Block range and result size are different constraints. Bracketed observes real RPC responses, keeps their reasons, and shows the uncertainty instead of hiding it behind a single number.
Measurements come from one host, with one User-Agent. They describe that vantage point—not global provider availability. The background sculpture is an original visual metaphor, not a chart.
Colours are bracketed's own; no affiliation with or endorsement by any provider.
How to read the ruler
The solid line is the largest observed successful span. The hatched segment is the gap to the smallest observed failed span. It is uncertainty, not capacity. “At least” means no definitive refusal was found up to that point—not an unlimited endpoint. A rate limit or other transient refusal bounds nothing; it is counted beside the bracket. A dashed line, when present, is the advertised cap. The axis is logarithmic: equal distances represent powers of ten.
Why the limit can move
Result size follows live log density. A span can succeed at one moment and fail later. Contradictory observations are labelled as a moving limit, never rendered as a precise bracket. A superseded bisection is preserved in words with its timestamps. Times labelled UTC are UTC.
The one-block counting convention
A probe uses fromBlock = head − span and toBlock = head, covering span + 1 blocks. A result exactly one block below a provider's inclusive advertised cap may therefore be the inclusive-counting convention, not a hidden limit. The verdict comes from the API.
Different windows, different questions
The evidence selector changes the failure-aggregation window. Coarse span brackets use recent observations, capped at one hour; a still-valid, more precise bisection carries its age. A rate from fewer than 20 measurable reads is explicitly marked indicative. Neither missing data nor an unmeasurable rate is shown as zero.
What never counts as their failure
A bad API key or a configuration mistake belongs to us. If a provider serves more than our read cap, it answered successfully; we stopped reading. These observations stay visible but are excluded from the failure-rate denominator.