Globalping

@Globalping run a ping measurement to example.com from 5 probes in Europe and show me the average latency

Created measurement ID msr_abc123 targeting example.com from 5 European probes. Results: Average RTT 24.3ms across probes in London (18ms), Frankfurt (22ms), Paris (26ms), Amsterdam (21ms), and Stockholm (34ms). All probes reached the target successfully with 0% packet loss. The Stockholm probe showed slightly higher latency due to geographic distance.

This example demonstrates the core measurement-creation workflow. The MCP returns probe-level detail, which the AI can aggregate into averages or identify outliers. Requires an API key with measurement-creation scope. Each measurement consumes credits based on probe count and test type.

@Globalping list all online probes in Asia with at least 100 Mbps bandwidth and show their network providers

Found 47 online probes matching your criteria across Asia. Sample: Tokyo (AS2516 KDDI, 1Gbps), Singapore (AS4657 StarHub, 500Mbps), Seoul (AS9318 SK Broadband, 200Mbps), Mumbai (AS55836 Reliance Jio, 150Mbps), Hong Kong (AS9381 HKBN, 1Gbps). Full list includes probes from 12 countries with bandwidth ranging from 100Mbps to 10Gbps. Note: probe availability fluctuates as volunteers connect/disconnect.

This read-heavy example shows how to filter the probe inventory by region and capability. Useful for planning measurements before creating them. Probe metadata includes ASN, ISP, city, and current status, but the live count changes minute-to-minute as community-run probes come online or go offline.

@Globalping create traceroute measurements to our staging server 203.0.113.45 from 3 probes per continent, then summarize which regions have routing issues

Created 6 measurements (msr_def456 through msr_def461) with traceroute to 203.0.113.45 from probes in North America, Europe, Asia, South America, Africa, and Oceania. Analysis: North America and Europe show clean 8-12 hop paths with sub-100ms latency. Asia probes encounter 15+ hops with packet loss at hop 9 (AS174 Cogent peering). South America sees 200ms+ latency but no loss. Africa and Oceania measurements still pending (typical 30-60s completion time for traceroute).

This synthesis example pairs measurement creation with AI-driven analysis of routing topology. The MCP returns raw hop-by-hop data; the AI identifies patterns like peering bottlenecks or asymmetric paths. Traceroute measurements take longer than ping and cost more credits. Results arrive asynchronously—poll the Get Measurement Results tool for completion.

When Globalping catches regional outages your monitoring missed

A 6-person SaaS team ships a feature behind a new CDN edge. US users report success, but Southeast Asia tickets pile up claiming the app is down. Your uptime monitor shows green because it pings from two US data centers. Globalping is the right call here: trigger measurements from 8-10 probes across APAC in under a minute, see which edge nodes are timing out, and route the fix to your CDN vendor with proof. The API key setup takes 90 seconds. The measurement tool returns latency and traceroute per probe, so you know if it's DNS, TLS, or the origin. If you're debugging once a quarter, this beats standing up your own probe network. If you're doing this daily, you want a dedicated monitoring platform with alerting.

How a 3-person team validates global reach before go-live

A startup with one backend engineer is launching in 12 countries next week. They need to confirm the API responds under 500ms from each region and that firewall rules aren't blocking traffic. Globalping's Create Measurement tool lets them script a pre-deploy checklist: ping the staging URL from probes in all 12 target markets, collect the results with Get Measurement Results, and fail the deploy if any probe times out. The 4-tool scope is narrow enough that a junior dev can own the integration in an afternoon. This works until you hit 50+ regions or need continuous monitoring—at that scale, the per-measurement API pattern gets expensive and you want a platform that stores historical trends. For launch validation, it's the fastest path to proof.

When support needs proof the slowness isn't your backend

A 10-person B2B company gets a ticket: 'Your dashboard is unusable from our Sydney office.' The backend logs show 80ms response times. Support suspects the customer's ISP or a peering issue, but needs data to escalate. Globalping's List Probes tool shows 4 active probes in Australia; Create Measurement runs a traceroute and latency test from each. Results come back in 20 seconds: two probes hit the app in 90ms, two time out at a specific hop owned by the customer's carrier. Support forwards the measurement ID to the customer's IT team with a one-line summary. This scenario works because the measurement is disposable—you're not storing it, just generating proof for a single ticket. If your support team needs this weekly, script it into a Slack command. If you need it hourly, you've outgrown the ad-hoc API model.