A monitor that checks your site from one place tells you one thing: whether your site is up from that place. It will not tell you that your Polish customers have been getting 4-second TLS handshakes for a week, that one upstream is blackholing a /24, or that a DNS resolver in one country is still handing out the address you retired on Tuesday. Those are the failures that generate support tickets while your dashboard stays green.
Running your own probes in several countries fixes that, and it is far cheaper than most people assume: five 2 GB machines in five EU countries is €25 a month at our prices, and you can test the idea for pennies on hourly billing before committing to any of it.
What multi-location probing actually catches
- Route-level problems. A transit or peering issue affects some paths and not others. A probe in Warsaw and a probe in Amsterdam disagreeing is the clearest signal you will get that the problem is the network, not your application.
- Regional DNS. Resolvers cache differently and negative-cache for different periods. Checking name resolution from several countries catches a propagation problem your own resolver has already forgotten about.
- Certificate and TLS oddities. Middleboxes, filtered ports and inconsistent TLS support show up as per-country handshake failures.
- Real latency, from real places. Not the synthetic number on a hosting company's marketing page — the number your users get, measured continuously.
- Your CDN's behaviour. If you sit behind a CDN, per-country probes tell you which edge is serving stale objects or failing to reach your origin.
The cheapest sensible layout
One small machine per location, plus one slightly bigger machine to collect and alert. Our entry shape — VPS I KVM, 2 GB RAM, 1 vCPU, 20 GB disk — is plenty for a probe running HTTP, TLS, DNS and ICMP checks every 30 seconds:
| Role | Shape | Location | Per month | Per hour |
|---|---|---|---|---|
| Probe | VPS I KVM | Bucharest | €4.00 | €0.0056 |
| Probe | VPS I KVM | Warsaw | €5.00 | €0.0070 |
| Probe | VPS I KVM | Amsterdam | €5.00 | €0.0070 |
| Probe | VPS I KVM | Frankfurt | €5.50 | €0.0077 |
| Probe | VPS I KVM | Vienna | €5.50 | €0.0077 |
| Five probes, five countries | €25.00 | €0.0350 | ||
| Collector + dashboard + alerting | VPS II KVM | your choice | €6.00–€9.00 | €0.0083–€0.0125 |
Around €31–€34 a month for continuous monitoring from five EU countries with the data staying on machines you control. Because probes are meant to run permanently, use the monthly price for them: hourly billing reaches the monthly figure at roughly 720 hours, so it is the wrong tool for anything always-on. Hourly is the right tool for the investigation — more on that below.
Tooling, in order of how much work you want to do
Least work: one self-hosted monitor per probe
Uptime Kuma or Gatus on each probe, each one checking your endpoints independently and notifying the same webhook. Ten minutes per box, no central component to build. The weakness is that you get five independent opinions and no aggregated view, so a single upstream wobble pages you five times.
Middle ground: blackbox exporters plus one collector
Prometheus blackbox exporter on each probe, one Prometheus on the collector scraping all five, Grafana on the same box for dashboards, Alertmanager for routing. This gives you the thing that matters: a query that says "how many locations currently consider the target down". Alert on count(probe_success == 0) >= 2 and single-path noise stops paging you at 3am.
A 2 GB probe runs a blackbox exporter with dozens of targets comfortably. The collector is the box that needs headroom — Prometheus with 5 probes, 30-second scrapes and a few months of retention fits in a 4 GB machine, and the 8 GB shape is the comfortable choice if you add per-endpoint histograms.
Most work, best data: probes that also trace
Add periodic mtr or traceroute from each probe to your production addresses, and store the output when a check fails. When your provider asks "where does it break", you will have the answer from five vantage points instead of a screenshot of a downtime graph. This is the difference between a support ticket that gets escalated and one that gets a template reply.
Use hourly probes for questions, not for monitoring
The permanent fleet answers "is it up". Hourly machines answer specific, temporary questions cheaply:
- "Customers in Poland say checkout is slow since Monday." A VPS I in Warsaw at €0.0070 per hour, running your checkout flow every minute for three days, costs about €0.50.
- "Is our new CDN configuration better from Austria?" Two probes, four hours, two locations: about €0.06.
- "Did that route flap affect Amsterdam only?" Bring up a probe there, leave it a day, destroy it: €0.17.
An hourly service needs €5 of account credit to start and bills from that balance each hour; destroying the machine is what stops the meter, not powering it off. For a three-day experiment, that is the whole operational overhead.
Practical details people get wrong
- Probe your own dependencies, not just your homepage. A 200 on
/with a dead payment provider is not "up". Check the endpoints that represent a working transaction. - Check IPv4 and IPv6 separately. Dual-stack failures are almost always one family only, and a probe that resolves to whichever family it prefers hides them.
- Do not put all the probes on the same provider. Including us. Five machines behind one network share one failure domain — keep at least one probe somewhere else entirely, so you can tell "our monitoring is broken" from "the internet is broken".
- Keep the collector away from the thing it monitors. If production and the collector live in the same location, the outage takes your alerting with it.
- Watch the disk. A 20 GB probe filling with a year of logs is the most common self-inflicted probe failure. Ship logs off or rotate aggressively.
Why this is worth doing yourself
Commercial multi-location monitoring is priced per check per location, which is precisely the axis you want to expand once it starts being useful. Five of your own probes cost €25 a month regardless of whether you check ten endpoints or four hundred, the raw data stays yours, and you can run anything you like on them — including tools that no SaaS monitor offers, like a traceroute captured at the moment of failure.
The trade-off is honest: you now operate six more Linux machines. Patch them, monitor the monitors, and accept that a probe going down is not an outage. If that sounds like more than you want to own, a hosted monitor plus one or two of your own probes in the countries you care about is a reasonable middle path.
How Noded Can Help
All five of our locations carry the VPS I shape, so a five-country probe fleet is five orders on the hourly VPS page with a different location selected each time — Bucharest, Warsaw, Amsterdam, Frankfurt and Vienna. Take them on the monthly price for the permanent fleet and use hourly for one-off investigations. The location price list has every figure, and our own status page is where we publish incidents on our side.
If you want a hand sizing the collector, or you are trying to work out whether a problem your customers report is yours or ours, open a ticket — bring the probe output and we will read it with you.
FAQ
How many locations do I need?
Two catches most single-path problems; three lets you use majority agreement to suppress false alarms. Five is useful if your customers are spread across Europe and you want per-country latency history.
Is a 2 GB VPS enough for a monitoring probe?
Yes. HTTP, TLS, DNS and ICMP checks against dozens of targets are not demanding. The machine that needs memory is the one storing and querying the results.
Should the probes be on hourly or monthly billing?
Monthly. Probes run continuously, and hourly billing costs the same as the monthly price at about 720 hours and slightly more beyond it. Keep hourly for temporary probes you create to answer a specific question.
Can I monitor from outside the EU with you?
Our live VPS locations today are all in the EU: Romania, Poland, the Netherlands, Germany and Austria. For a non-EU vantage point, use a probe elsewhere — which is good practice anyway, since it keeps one probe outside our failure domain.
What should trigger an alert?
Agreement between locations, not any single failure. Alerting when two or more probes fail the same check at the same time removes most of the noise that makes people ignore monitoring.