Methodology
FetchGauge is designed as an independent benchmark platform for Web Data infrastructure. This deployment demonstrates the interface and calculation pipeline with deterministic sample data.
What you are seeing
Every provider metric, historical line, error share, price and capability flag comes from the local design fixtures. No provider has been contacted or benchmarked. “Tested 14 min ago” and “last benchmark 18 minutes ago” are fixed design-clock labels, not claims of recent activity.
The provenance header describes the intended production protocol: “FetchGauge probes · self-funded accounts · no vendor-supplied data”. In this demo there are no real probes or funded accounts. All provenance panels carry a Demo data label.
Intended measurement protocol · v2.3
Run an identical target set for each eligible provider, from the same region and hourly window. The design fixture specifies 50 e-commerce targets, 50 concurrent requests, a 30-second timeout and at most 3 retries. A run contains 1,284 sample requests; period totals are hourly run counts multiplied by that sample size.
Success means an HTTP 200 response with the expected content selector present. Soft blocks fail that check. Latency covers time to the full response, including provider retries. Report the p50 and p95 independently and retain the error categories.
Reliability score
The design describes a score weighted 60% success, 25% p95 stability and 15% error diversity. The six scores in this deployment are canonical fixture inputs. The design does not specify normalization for the stability and diversity components, so the app does not invent or recompute a production reliability formula.
Before a real runner is connected, publish and version those normalizations and test them on stored raw observations. The comparison marks differences of at most 2 score points as within the design’s sample noise allowance; that allowance is not a statistical confidence interval.
Cost model · v1.4
The calculator follows the design’s exact model. Per-1,000 request cost starts with the provider base price and multiplies by the JS factor when enabled, then region, page size and concurrency factors.
regionMult: global / US 1, EU 1.05, APAC 1.15, LATAM 1.2. sizeMult = 1 + max(0, sizeMB − 1) × 0.12. Concurrency adds a factor of 1.05 at 200, or 1.15 at 1,000.
Let eff = success / 100. Retry overhead is max(0, target / 100 − eff) × 1.5. Monthly cost is the greater of the provider minimum and requests / 1000 × per1k × (1 + retries). The overhead is a pricing assumption, not a guarantee that retries achieve the target.
Plan labels are derived from monthly totals: below $300 Pay as you go; below $1,200 Growth; below $5,000 Business; otherwise Enterprise. These labels are model bands, not verified provider products.
okPer1k = per1k / eff. This normalized request-cost metric excludes the monthly plan floor and target retry overhead. The benchmark’s JS scenario also adjusts success and latency; the calculator faithfully uses the unadjusted success rate specified by its separate formula.
Scenario limits
The JS benchmark adjustment subtracts 2.5 success points for a JS multiplier above 4, otherwise 0.8; adds 1.1 seconds to p50 and 2 seconds to p95; and multiplies request cost by the provider’s JS multiplier. Period changes alter the seeded series length and sample totals.
Region, target count and non-JS workload selections update provenance but have no invented performance penalty. Categories filter on the sample capability flags. The same canonical provider metrics are reused across the sample categories. They are not separate real measurements.
Independence
Score ordering and recommendations are driven by data and explicit rules. Affiliate destinations never participate in ranking logic. Outbound pricing links are outlined, disclosed and marked sponsored. The benchmark dashboard and calculator contain no affiliate calls to action.