Globalping: network tests run from probes around the world

A measurement network you address like an API

Globalping is a global network of probes to run network tests like ping, traceroute and DNS resolve, and the platform description is explicit about the goal: a free, user-friendly API for everyone to build interesting networking tools and services.

The mechanics are simple enough to explain in one paragraph. You submit a measurement describing a target, a test type and where you want it run from, the platform schedules it against a probe in that region, the probe executes the actual command, and the result comes back with the raw output. The website lists the commands it supports as ping, traceroute, dig and mtr.

What you get back is deliberately close to the command output. The README's own traceroute example shows a plain hop-by-hop listing with per-hop times, alongside the probe's location and network, in this case a Frankfurt probe in an EU network and a Zwolle probe in an NL network. That matters for the use cases the project lists: troubleshooting anycast issues, monitoring CDN and DNS performance, performing uptime monitoring, and building your own network tools.

The framing at the top of the README is about gaining insight into network routing from any location in the world, and the useful consequence of that is that a measurement is a request against somebody else's vantage point. When a hostname resolves differently in different regions, or an anycast address lands on a different pop depending on where the packet came from, this is how you find out.

Three ways in, one API underneath

The platform says that many users will prefer alternative ways to use it rather than working directly with the API, and that the tools are all built on the same API surface.

The CLI is for people who feel at home in a terminal. It installs on Linux, macOS and Windows through the usual package managers, and the README gives the commands for each, from apt and dnf through Homebrew, winget and chocolatey. A traceroute from the CLI looks like this:

$ globalping traceroute google.com from Western Europe --limit 2
> EU, DE, Frankfurt, ASN:210546
traceroute to google.com (142.250.185.78), 20 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.747 ms  0.714 ms
 2  10.2.0.97 (10.2.0.97)  5.482 ms  5.511 ms
 3  10.10.0.1 (10.10.0.1)  613.232 ms  613.268 ms
 4  ae6-ffm21.core2.ffm3.de (45.138.175.101)  9.150 ms  9.188 ms
 5  ae1-core2.core3.ffm3.de (45.138.175.105)  6.027 ms  6.030 ms
 6  142.250.171.196 (142.250.171.196)  5.562 ms  5.749 ms
 7  209.85.244.249 (209.85.244.249)  48.691 ms  48.812 ms
 8  142.250.209.243 (142.250.209.243)  5.742 ms  5.743 ms
 9  fra16s48-in-f14.1e100.net (142.250.185.78)  5.716 ms  5.717 ms

The web tools are for on-the-go testing and visual presentation, and the website shows the probes used on a map for each test with detailed results below. The Slack app brings the same capability into a workspace, and the README describes it as especially handy for NOC, OPS and support teams collaborating on networking issues and discussing results.

The REST API is for building something custom. Creating a measurement is a POST with a JSON body:

POST https://api.globalping.io/v1/measurements
{
    "limit": 10,
    "locations": [],
    "target": "jsdelivr.com",
    "type": "ping",
    "measurementOptions": {
        "packets": 5
    }
}

The body carries the number of probes to use, an optional location filter that is empty here to mean anywhere, the target, the measurement type, and the options for that type. There is a full API documentation site and a developer demo at the API host.

The API service is a Koa app on Redis, Postgres and Elasticsearch

This repository is the API server, and the package manifest is named globalping-api at version 1.0.0. It is an ES module project whose entry point is dist/src/index.js.

The web stack is Koa, with the router from @koa/router, and the middleware list is telling: koa-bodyparser, koa-compress, koa-conditional-get, koa-favicon, koa-json, koa-response-time and koa-static. Socket.io is there too, with the Redis adapter, which is how the platform pushes results to waiting clients instead of having them poll.

The data side is three stores. Postgres, through pg and knex, with separate knexfiles for the dashboard, the measurement store and a time-series database, and migrations in the repository. Redis, used both as a queue and for caching, with bullmq as the queue library, ioredis-style client and the ttlcache package. Elasticsearch, through @elastic/elasticsearch, for the measurement data that gets queried and aggregated.

Everything else in the dependency list supports those three. The measurement pipeline uses @martin-kolarik/batch-queue to group work, @node-rs/xxhash for fast hashing, rate-limiter-flexible for the rate limits, and a maxmind GeoIP database with the geoip2-node client to turn an address into a location, with countries-list and cidr-tools for the network information that goes with it.

The API is documented with OpenAPI, and the project uses @redocly/openapi-core alongside two Spectral configuration files, one of them named for Adidas, which suggests a linting setup carried over from another codebase at the same organisation. The documentation is generated from the spec rather than written by hand, and the README points to a separate documentation site for the user facing material.

The probe network is the scarce resource, and it runs on donated hardware

Globalping needs probes in many places, and they are provided by the community. The support section explains the arrangement: the platform relies on a globally distributed network of probes for running network measurement requests, and the project will list anyone who can host at least six probes as a donor on GitHub and on the website.

There are two other routes to hardware. Becoming a GitHub sponsor of jsDelivr supports both the CDN and the platform, and sponsors contributing 10 dollars or more per month can request a hardware probe to install in their home or office. And a company can sponsor a batch of co-branded hardware probes, with its own stickers and swag, to ship to its users or hand out at conferences.

The commercial sponsors listed are Gcore, xTom and Edis Global, and the README frames the community contributions as supporting the probe network's growth.

For a user, the practical consequence is that the probe pool is a mix of home connections, office links and hosted machines. That is what makes the service free and it is also what shapes the results: a probe is a real network with its own peering and its own congestion, and the hop-by-hop output of a traceroute from a home connection is not the same thing as a measurement from a well-peered datacentre. The CLI output makes that visible, since each result is labelled with the city, the country and the ASN.

Credits are the other side of the model. Registering on the Globalping dashboard increases your limits, and adopting probes earns you free credits, so the network is kept in circulation by the people who use it.

Self-hosting the API means self-hosting the infrastructure

If you want to run the API yourself, the repository layout is the instruction sheet. There is a docker-compose.yml and a docker-compose.dev.yml, a compose-stack.yml, a Dockerfile, and an INFRASTRUCTURE.md.

The compose file is a Redis topology, and it is elaborate. Three standalone Redis instances on ports 7001, 7002 and 7003, each from the redis-stack-server image with its own configuration file, a data volume and an environment file, and a three node cluster built from a custom image. The cluster nodes run with host networking and a per-node script and port, 7101 through 7103, and every service carries a stop_grace_period of 3m, which is a long shutdown window and tells you the queue drains slowly.

The application image is a two-stage build on node:26-bookworm-slim. The builder installs a native toolchain including python3, make and g++, installs dependencies with dev included, copies the source and runs the build. The runtime stage installs the same native dependencies, copies only the built dist and data directories from the builder, and runs the API as a non-root style process under tini, with the port set to 80 and the heap limits passed on the command line, a 1600 MB old space and a 128 MB semi-space, plus the Elastic APM loader started through an experimental loader hook.

So the operational cost of self-hosting is real: a Redis cluster, a Postgres, an Elasticsearch, and a Node service with APM wired in. That is what the platform's own hosted offering exists to avoid, and for most users the sensible arrangement is to use the hosted API and spend the engineering effort on the tooling that consumes it.

Where Globalping is the wrong tool

The first limitation is that the probe pool is shared and finite. Every measurement consumes capacity that someone else also wants, the credits system exists because of it, and the README's own contribution model shows that the network grows by people donating hardware. If your monitoring needs are continuous, you will be rationing, and the results of a busy period are affected by other people's traffic on the same probes.

The second limitation is what a probe can tell you. Globalping runs standard network commands from a probe's vantage point, which means it sees what that probe sees: its own routing, its own DNS resolution, its own peering. It does not see your users, it does not see your own network path to the target, and it does not measure the application layer beyond what the protocol gives it. A latency number from a Frankfurt probe tells you about Frankfurt.

The third limitation is the trust model. The result is the output of a command run on a machine you do not own, delivered over a public API, and the service is free. For interactive debugging that is a fine trade, and for a permanent monitoring pipeline it is a decision to make explicitly rather than by default.

The real alternative is your own agents, and the difference in approach is the whole point. A ping from your own infrastructure in each region is a measurement of your own path and your own peering, which is what you usually want to know when you own the service. The cost is that you need a host in every region you care about, and that is exactly the cost Globalping exists to avoid, by asking the community for the hardware instead. The middle path, and the one the project structure hints at, is to use Globalping for the questions that are cheap to ask of strangers, such as where does this anycast address land, and to keep your own agents for the questions about your own service.

Editorial conclusion

Adopt Globalping if you need to see how a service behaves from other networks, for anycast debugging, CDN and DNS monitoring, or an uptime check from several regions at once, and if you can live with the limits of a shared, rate-limited public service. Do not adopt it for continuous monitoring at a scale the free limits do not cover, since the credits model and the shared probe pool are designed for interactive diagnosis rather than a permanent agent, and do not treat it as a substitute for your own agents. Before you build on it, read the API documentation and the measurement options for your test type, and register on the dashboard if you need higher limits or want to adopt probes to earn credits.

Frequently asked questions

Official sources

1. Issues
2. jsdelivr/globalping on GitHub
3. Project website
4. README