Published: 24 September 2026
Single-location monitoring answers one question: can the monitor reach you? That is useful, and it is not the question your users are asking. They want to know whether the site works from where they are, and a probe in one city cannot tell you that. Worse, it produces a specific kind of false confidence: everything green while an entire country cannot reach you because of a routing problem between their transit provider and yours.
Running your own probes in several countries fixes that, and it is cheap enough that the reason not to do it has to be something other than money.
What it costs
A probe is a tiny job. It opens a connection, measures, and writes a result. The 2 GB plan is more than enough, and a probe in each of our five countries looks like this:
| Probe location | Plan | Per month | Per hour |
|---|---|---|---|
| 🇷🇴 Bucharest | VPS I KVM (2 GB / 1 vCPU / 20 GB) | €4.00 | €0.0056 |
| 🇵🇱 Warsaw | VPS I KVM | €5.00 | €0.0070 |
| 🇳🇱 Amsterdam | VPS I KVM | €5.00 | €0.0070 |
| 🇩🇪 Frankfurt | VPS I KVM | €5.50 | €0.0077 |
| 🇦🇹 Vienna | VPS I KVM | €5.50 | €0.0077 |
| All five, monthly | €25.00 | — | |
Twenty-five euro a month, before VAT, for five vantage points in five EU countries, each a full KVM machine with root that you can also use to run a traceroute when something looks wrong. The full price grid for every plan is in our location pricing post.
These are permanent machines, so put them on the monthly cycle — the hourly option exists for servers with an end date, and a probe does not have one. Annual is 10% below twelve months at the base rate if you would rather pay once.
What to actually measure
A probe that only records up or down wastes four fifths of its value. From each location, record:
- DNS resolution time — separately from the request. A slow resolver in one country is a real failure mode that looks like a slow site.
- TCP connect and TLS handshake time — these isolate the network path from your application. If connect time doubles in Warsaw and nowhere else, the problem is not your code.
- Time to first byte — your application's latency, once the connection exists.
- Total transfer time and bytes — catches a CDN serving an uncompressed or wrong-region response.
- The response body assertion — a 200 that renders an error page is the outage people miss. Check for a string that only appears when the page actually worked.
Keep the raw per-probe samples, not just an average. The interesting signal in multi-region monitoring is almost always a divergence between locations, and an average across five vantage points destroys exactly that.
Wiring it up
Probes push, they do not get polled
Have each probe write its results outward to a collector rather than having a central server scrape five machines. A scrape that fails tells you nothing about whether the probe or the path to it broke, and it means five inbound firewall holes. A push keeps the probes closed to the world.
The collector should not live with the thing it watches
If your application is in Frankfurt, put the collector somewhere else — Bucharest is our cheapest location and perfectly suited to it. A monitoring stack that goes down in the same event as the service it monitors is decoration. Our post on running Prometheus, Grafana and Loki on your own VPS covers the collector side properly, and Uptime Kuma is the lighter option if you mainly want a status page.
Alert on agreement, not on any single probe
One probe failing is a probe problem. Three of five failing is your problem. Requiring agreement across locations removes most of the noise that makes teams mute their alerting, and the disagreement itself is a diagnosis: if only Warsaw is red, look at the path, not the application.
Keep the probes boring and identical
Same operating system, same version, same configuration, deployed the same way. A probe fleet that has drifted is a fleet that measures five slightly different things. Twenty-six install images are on our order form; pick one and use it five times.
What five locations can and cannot tell you
Be honest about the limits. Our VPS footprint is Romania, Poland, the Netherlands, Germany and Austria — five EU countries. That gives you good coverage of central, eastern and western Europe and tells you nothing about how your site behaves from São Paulo or Singapore. It also measures the datacentre path, not the consumer path: a probe sitting on a well-peered exchange is a better-connected client than any of your actual users.
What it does catch, reliably: regional routing failures, a CDN pop serving stale or broken content in one country, DNS problems that are specific to one resolver, TLS certificate issues that only appear on some paths, and the slow degradation of a transit link that never quite goes down.
A cheaper first step
If five machines is more commitment than you want, start with two — one in Frankfurt and one in Bucharest, at the two ends of our footprint, for €9.50 a month. That single pair catches most east-west routing problems, and you can add the other three when it earns the budget. Pick a size on the VPS page and choose the country in the location list.