This site is not affiliated with or endorsed by Cloudflare, Inc. It showcases deployable experiments across most Cloudflare products.
Network & Monitoring

Multi-PoP Latency Map

Measure fetch latency and report the Cloudflare colo that served the Worker - edge PoP latency visibility for any URL

Fetch a target URL from the edge and report response time plus the Cloudflare colo (cf.colo) that handled the Worker invocation. Documents honestly that each request runs in a single PoP - not a global multi-region sweep.

Features

  • GET /latency?url= - Response time, status code, and edge location
  • Colo metadata - colo, city, country from request.cf
  • Transparent limitations - Response includes limitation and tip fields
  • Cache bypass - Uses cf: { cacheTtl: 0 } on the outbound fetch

API Reference

GET /latency

Measure fetch latency from the current edge location.

Prop

Type

Example Request

curl "https://your-worker.workers.dev/latency?url=https://www.cloudflare.com"

Success Response

{
  "url": "https://www.cloudflare.com/",
  "responseTimeMs": 87,
  "statusCode": 200,
  "colo": "SFO",
  "city": "San Francisco",
  "country": "US",
  "timestamp": "2025-06-20T12:00:00.000Z",
  "limitation": "Each Worker invocation runs in a single Cloudflare PoP...",
  "tip": "For multi-region comparison, call this endpoint repeatedly from different client locations..."
}

Error Codes

  • 400 - Invalid URL (INVALID_URL)
  • 502 - Fetch failed (FETCH_ERROR)

This endpoint reports latency from one PoP per request. It does not perform a simultaneous multi-region ping. Call repeatedly from different geographic clients to compare colos.

Use Cases

  • Show students how request.cf.colo identifies the serving edge
  • Compare latency when calling the worker from different client locations
  • Learn honest edge networking constraints in Workers

Limitations

  • Single PoP per invocation; no built-in multi-region orchestration
  • colo reflects where the Worker ran, not every hop to the origin
  • Outbound fetch timing includes DNS + TLS + TTFB for the target URL

Use in your project

Copy these files into an existing Worker. Prefer Deployment to try the full experiment first. Source: apps/experiments/multi-pop-latency-map.

DependenciesNoneBindingsNonePlatformWorkers runtime
import { ALLOWED_SCHEMES } from "../constants/defaults";export function validateUrl(input: string | undefined): string | null {  if (!input || typeof input !== "string") return null;  const trimmed = input.trim();  if (!trimmed) return null;  try {    const url = new URL(trimmed);    if (!ALLOWED_SCHEMES.includes(url.protocol as (typeof ALLOWED_SCHEMES)[number])) {      return null;    }    return url.href;  } catch {    return null;  }}export function getCfLocation(cf: { colo?: string; city?: string; country?: string } | undefined) {  return {    colo: cf?.colo ?? null,    city: cf?.city ?? null,    country: cf?.country ?? null,  };}

Deployment

Click the deploy button

Deploy to Cloudflare Workers

Test your deployment

curl "https://your-worker.workers.dev/latency?url=https://example.com"

Local Development

cd apps/experiments/multi-pop-latency-map
npm install
npm run dev

colo and geolocation fields are populated when deployed to Cloudflare's edge. Local wrangler dev may return null for some cf properties.

Cloudflare Features Used

  • Workers - Edge compute runtime
  • request.cf - Colo and geolocation metadata
  • Fetch API - Outbound HTTP with cache controls

On this page