How to test your server's internet speed
A VPS has no browser, so the usual speed test is no help when you want to know what your server's connection actually does. PulseTest installs a small command you can run over SSH. It measures the same things this website does — download, upload, latency and jitter — and prints the result straight into your terminal.
In a hurry? Paste the install command from Step 2 into your server, then type pulsetest. That's the whole process. The steps below just explain what each part does.
Before you start
You need three things. Almost every server already has all of them.
- A Linux or macOS server you can log into over SSH. Windows Server isn't supported — use this website in a browser instead.
curlandawk, which ship with essentially every server image. If either is missing, install it with your package manager first.- Root or
sudoaccess, used once to place the command in/usr/local/bin. The test itself runs fine as an ordinary user afterwards.
Installation, step by step
Log into your server
From your own computer, open a terminal and connect over SSH. Replace the username and address with your own.
Everything from here on is typed on the server, not on your own machine.
Run the install command
Paste this one line and press Enter. It downloads the script and places a single file at /usr/local/bin/pulsetest.
It finishes in a second or two and prints a confirmation. Nothing else is added to your system — no service, no cron entry, no configuration directory, no packages.
Run your first test
Type pulsetest and press Enter. That is the whole command — no flags, no arguments, nothing to configure. speedtest works too: the installer sets up both names for the same tool, so use whichever you remember.
The test takes about twenty seconds: latency first, then download, then upload. You'll see live figures while each stage runs.
What you'll see
This is the finished output of a real run. Latency, download and upload each get their own panel with a live bar, and the summary at the bottom collects the four headline numbers.
| Reading | What it tells you |
|---|---|
| Download | How fast your server pulls data in. This is what matters for fetching packages, pulling images and restoring backups. |
| Upload | How fast your server pushes data out. This is what your visitors actually experience when they download from you, and it is often much lower than the download figure. |
| Latency | The round-trip delay to the test server. Largely a function of physical distance, so a server far from the test location will always read higher. |
| Jitter | How much that delay varies. Low jitter means a steady connection; high jitter is what makes calls and streams stutter even when the speed looks fine. |
| Streams | How many connections ran at once. One connection cannot fill a fast link that has any real distance on it, so several are used in parallel — a single-stream test would under-report a good server badly. |
Options
The animation only appears in an interactive terminal. Redirect the output anywhere else and it automatically switches to plain text with no colour codes and no progress frames, so logs stay readable.
| Option | What it does |
|---|---|
-q, --quiet | A single line per run. Made for cron and log files. |
-j, --json | Machine-readable JSON, for piping into jq or a monitoring script. |
-s, --simple | Human-readable, but with no animation. |
--no-color | Turn off colour. The NO_COLOR environment variable is honoured too. |
-t, --time SECS | Seconds per direction. Default 8, minimum 3, maximum 30. Longer is steadier on an unstable link. |
-h, --help | Show every option. |
Running it on a schedule
Use --quiet for scheduled runs: one timestamped line per test, no colour, no animation. This runs it every hour and appends to a log file.
After a few days that log will show whether your server slows down at particular hours — something a single test can never reveal.
Uninstalling
The installer only ever writes one file, so removing it is one command. Nothing is left behind.
Reading the script before you run it
Piping anything from the internet into sudo bash means trusting whatever the server sends back. That is a sensible thing to be careful about, so the script is served as plain text and you are welcome to read all of it first.
If something goes wrong
| What you see | What to do |
|---|---|
pulsetest: command not found | The install step didn't finish, or /usr/local/bin isn't on your PATH. Try the full path: /usr/local/bin/pulsetest. |
requires curl | Install it first — apt install curl on Debian and Ubuntu, dnf install curl on Fedora and RHEL. |
| Could not reach the server | Your server's firewall is probably blocking outbound HTTPS, or DNS isn't resolving. Check with curl -I https://cerus.eu.org. |
| Speeds look far too low | Check how far your server is from the test location — the latency figure tells you. A server in Asia tested against Europe is partly measuring the distance, not a fault. |
Results reflect the path between your server and this test server, which sits in a specific place. Test against the region closest to you for the most useful number.
What people use it for
Checking a new provider
Confirm a host actually delivers the port speed they advertised, before you migrate anything onto it.
Diagnosing slow transfers
Separate "the server's uplink is slow" from "this one transfer is slow" — they look identical until you measure.
Tracking over time
Run it from cron and log the output to spot degradation that only appears at certain hours.