Why Your CI Runner Feels Slow: Using a Speed Test to Check Network Baselines

A slow CI runner is usually blamed on the runner itself, the build cache, or the cloud provider. But often the real bottleneck is the network between the runner and the services it talks to. Measuring a baseline with a speed test turns that guess into data.

The invisible dependency

CI pipelines constantly move data: cloning repositories, pulling container images, downloading dependencies, uploading artifacts. Every one of those steps is a network operation. If the runner's connection is degraded, the pipeline degrades with it, regardless of CPU or memory.

Establish the baseline

Before you can call a pipeline slow, define what normal looks like. Run a speed test from the runner host at different times of day, capturing throughput, latency, jitter, and packet loss. Wonder Signal logs each run automatically, so you can build a baseline profile instead of relying on a single lucky measurement.

Correlate with build times

When a build takes twice as long as usual, run a speed test at that moment and compare it with the baseline. If throughput is down or packet loss is up, the network is your prime suspect, and the fix is operational, not code. If the network is clean, focus on the registry, the cache, or the build definition.

A practical threshold

Treat the speed test as a pre-flight check for your pipeline health. Some teams even script it: if upload throughput drops below a threshold or jitter exceeds a limit, page the on-call engineer with the network data attached. It is a small addition that removes an entire class of mystery slowdowns from your daily debugging.