Monitor your stack from a second location, on a tiny VPS.
First month $1, then the normal monthly price. One per customer.
Uptime Kuma or Gatus on a small KVM VPS, placed in Amsterdam when your servers are in the US and in New York when they are in Europe. A status page for your users, cron monitoring in the style of Healthchecks.io, and Prometheus with Grafana for a small fleet. Full root, NVMe RAID10, unlimited traffic.
Transparent pricing
Plans and prices
| Plan | vCPU | Memory | NVMe | Traffic | Monthly | 1 year | |
|---|---|---|---|---|---|---|---|
| Standard | |||||||
| S-2Standard | 1vCPU | 2 GBMemory | 30 GBNVMe RAID10 | UnlimitedTraffic | $7.99/moFirst month $1 | $7.19/mo on 1 year | Start for $1 |
| S-4Standard | 2vCPU | 4 GBMemory | 60 GBNVMe RAID10 | UnlimitedTraffic | $13.99/moFirst month $1 | $12.59/mo on 1 year | Start for $1 |
| S-8Standard | 3vCPU | 8 GBMemory | 120 GBNVMe RAID10 | UnlimitedTraffic | $24.99/moFirst month $1 | $22.49/mo on 1 year | Start for $1 |
| S-16Standard | 4vCPU | 16 GBMemory | 240 GBNVMe RAID10 | UnlimitedTraffic | $44.99/moFirst month $1 | $40.49/mo on 1 year | Start for $1 |
| S-32Standard | 8vCPU | 32 GBMemory | 480 GBNVMe RAID10 | UnlimitedTraffic | $84.99/moFirst month $1 | $76.49/mo on 1 year | Start for $1 |
| S-64Standard | 16vCPU | 64 GBMemory | 720 GBNVMe RAID10 | UnlimitedTraffic | $159.99/moFirst month $1 | $143.99/mo on 1 year | Start for $1 |
| Dedicated CPU | |||||||
| D-4Dedicated | 1vCPU | 4 GBMemory | 45 GBNVMe RAID10 | UnlimitedTraffic | $37.00/moFirst month $1 | $31.45/mo on 1 year | Start for $1 |
| D-8Dedicated | 4vCPU | 8 GBMemory | 90 GBNVMe RAID10 | UnlimitedTraffic | $69.00/moFirst month $1 | $58.65/mo on 1 year | Start for $1 |
| D-16Dedicated | 4vCPU | 16 GBMemory | 160 GBNVMe RAID10 | UnlimitedTraffic | $118.00/moFirst month $1 | $100.30/mo on 1 year | Start for $1 |
| D-32Dedicated | 6vCPU | 32 GBMemory | 220 GBNVMe RAID10 | UnlimitedTraffic | $215.00/mo | $182.75/mo on 1 year | Deploy D-32 |
| D-64Dedicated | 10vCPU | 64 GBMemory | 400 GBNVMe RAID10 | UnlimitedTraffic | $377.00/mo | $320.45/mo on 1 year | Deploy D-64 |
| High Memory | |||||||
| H-64High Memory | 8vCPU | 64 GBMemory | 480 GBNVMe RAID10 | UnlimitedTraffic | $249.00/mo | $211.65/mo on 1 year | Deploy H-64 |
| H-128High Memory | 16vCPU | 128 GBMemory | 960 GBNVMe RAID10 | UnlimitedTraffic | $459.00/mo | $390.15/mo on 1 year | Deploy H-128 |
| H-192High Memory | 24vCPU | 192 GBMemory | 1.4 TBNVMe RAID10 | UnlimitedTraffic | $669.00/mo | $568.65/mo on 1 year | Deploy H-192 |
Four monitoring setups that fit on one small VPS.
Start with the first one. Add the others when you have a reason.
Uptime Kuma or Gatus as the outside eye
HTTP, TCP, ping, DNS and certificate checks every 20 to 60 seconds, with a history graph per check. Uptime Kuma is a UI you click through; Gatus is a YAML file you commit. Both fit on S-2 and both do the job for a few dozen checks.
A public status page
Both tools publish a status page from the same checks. Put it on its own subdomain, on the monitoring VPS, so it stays up when your main site does not. That is the whole reason the page exists.
Cron and backup monitoring, Healthchecks.io style
Uptime Kuma has push monitors: your backup script calls a URL at the end, and you get an alert when the call does not arrive in time. Self-hosted Healthchecks does the same with a nicer cron grammar. Silent failures of nightly jobs are what this catches.
Prometheus and Grafana for a small fleet
node_exporter on every server, Prometheus scraping them on the monitoring VPS, Grafana for dashboards and alert rules. Disk usage, memory, load and network per host. For a handful of servers this fits S-4.
Which plan for this workload.
Uptime checks are tiny. Metrics retention is what eventually needs a bigger plan.
| Setup | Plan | Why |
|---|---|---|
| Uptime Kuma or Gatus, up to a few dozen checks, status page | S-2 | One container and a SQLite database; 1 vCPU idles |
| Uptime Kuma plus self-hosted Healthchecks with Postgres | S-2 or S-4 | Healthchecks adds Postgres; S-4 keeps it comfortable |
| Prometheus and Grafana for a small fleet, default retention | S-4 | S-4 (2 vCPU, 4 GB, 60 GB NVMe) at €11.99 a month ($13.99): RAM for the TSDB, disk for retention |
| Longer retention, many exporters, Loki for logs | S-8 | Logs and long retention fill the 60 GB on S-4 quickly; S-8 has 120 GB |
Why a second region matters, in numbers we measured ourselves: from Amsterdam it is 9.0 ms to London, 8.5 ms to Frankfurt and 9.3 ms to Paris. From New York it is 5-8 ms to Boston and 10-15 ms to Toronto. Between Amsterdam and New York it is 75-90 ms. A check from the same city as your server sees a different network than your users in the other continent. Running the monitor across the ocean tells you what those users see, and it keeps working when the local facility or its upstream has a bad day. Both regions cost the same. If you also want checks without running anything, we sell uptime checks as an add-on at €7.00 a month; the self-hosted route on S-2 gives you the status page and the push monitors on top. See Amsterdam, New York and all locations.
Setting it up on BuyVPS.
Step 1: order in the other region, install Docker
Order an S-2 in the region your stack is not in. Pick Debian 13 or Ubuntu 24.04. Log in 30 to 60 seconds after payment and install Docker with the script the Docker project publishes.
apt update && apt upgrade -y curl -fsSL https://get.docker.com | sh ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
Step 2: Uptime Kuma with docker compose
One container, one data folder. Bind the port to localhost; Caddy will expose it over HTTPS in the next step. Pin the image tag to the major version you install, so an update does not surprise you.
# /opt/kuma/docker-compose.yml
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
volumes:
- ./data:/app/data
ports:
- "127.0.0.1:3001:3001"
mkdir -p /opt/kuma && cd /opt/kuma docker compose up -d
Step 3: Caddy in front, with TLS
Point an A record at the VPS, install Caddy from the repository the project documents, and add one site block. Uptime Kuma has its own login, so the dashboard is not open to the world. The status page is public by design.
# /etc/caddy/Caddyfile
status.example.com {
reverse_proxy 127.0.0.1:3001
}
systemctl reload caddy
Step 4: checks, notifications and the status page
Open the domain, create the admin account, and add monitors: an HTTP check with a keyword on your homepage, a TCP check on the database port if it is reachable, a DNS check, a certificate expiry check. Add a Telegram or Slack notification and a second channel such as email. Then create a status page and pick which monitors it shows.
Step 5: push monitors for cron jobs and backups
Create a push monitor in Uptime Kuma; it gives you a URL. Call it at the end of the job. If the call does not arrive within the period you set, you get an alert. This is the Healthchecks.io pattern, self-hosted.
# at the end of /usr/local/bin/backup.sh curl -fsS -m 10 --retry 3 "https://status.example.com/api/push/YOUR_TOKEN?status=up&msg=OK" > /dev/null
Step 6: Gatus, or Prometheus and Grafana, if you want config as code
Gatus reads a YAML file and needs no clicking. Prometheus with node_exporter on each host and Grafana on top goes on an S-4; keep the scrape endpoints on a private network or behind a firewall rule that allows only the monitoring VPS.
# /opt/gatus/config/config.yaml
endpoints:
- name: website
url: "https://example.com"
interval: 60s
conditions:
- "[STATUS] == 200"
- "[RESPONSE_TIME] < 500"
docker run -d --name gatus --restart unless-stopped -p 127.0.0.1:8080:8080 -v /opt/gatus/config:/config twinproduction/gatus:latest
Uptime Kuma's own documentation is at uptime.kuma.pet.
Pitfalls we see, and how to avoid them.
Monitoring from the same place as the thing you monitor
A monitor on the same server, or in the same facility, goes dark at the same moment as the site. Put it in the other region at least. If your whole stack is with us, the second region is a different city, a different facility and a different network path. If it is elsewhere, a BuyVPS box is your outside eye.
Alert fatigue
Ten alerts a day means none get read. Use retries before alerting, set sensible intervals, and alert on what a user would notice. Route noisy checks to a channel nobody is paged for. Review the list monthly and delete checks that never fire for a reason.
The dashboard open to the internet
Uptime Kuma has a login. Gatus and Grafana need one in front, or an admin password that is not the default. Caddy's basic_auth directive with a hashed password takes two lines. A monitoring dashboard leaks your whole hostname list to anyone who finds it.
Checking too often
A 5-second interval against an API with a rate limit gets the monitor blocked, and then reports an outage that is not there. Use 30 to 60 seconds for most checks, longer for third-party services, and stagger the start so they do not all fire at once.
Pick the region closest to your users.
For monitoring, invert the rule: put the monitor where your users are and your servers are not. A US stack watched from Amsterdam sees what European visitors see, and the reverse for New York. Prices are identical in both regions.
Questions about running Uptime Kuma on a VPS.
Is the S-2 plan really enough for Uptime Kuma?
Yes. Uptime Kuma is one Node.js process with a SQLite database and idles on 1 vCPU with 2 GB. A few dozen checks at 60-second intervals barely register. You would move to S-4 for Prometheus and Grafana, not for Uptime Kuma.
Why put the monitor in a different region?
So it keeps working when your main location has a problem, and so it measures what remote users experience. Between Amsterdam and New York we measure 75-90 ms; a check from across the ocean sees a path your local checks never touch. Prices are identical in both regions.
Can I host a public status page on it?
Yes. Uptime Kuma and Gatus both generate one from the checks you select. Give it a subdomain on the monitoring VPS, so it stays online while the main site is down. Caddy handles the certificate.
How do I monitor cron jobs and backups?
With a push monitor: the job calls a URL when it finishes, and you are alerted when the call is late or missing. Uptime Kuma has this built in, and self-hosted Healthchecks offers the same with cron-expression schedules. It catches the backups that silently stopped weeks ago.
Do you also sell uptime checks as a service?
Yes, as an add-on at €7.00 a month, if you would rather not run anything. Self-hosting Uptime Kuma on an S-2 costs €6.99 a month and adds the status page, push monitors and your own notification channels.
Which operating system should I pick?
Debian 13 or Ubuntu 24.04, both offered at order time. Everything here runs in Docker, so the choice hardly matters. Debian is the smaller install, which suits a box that runs one container.
Deploy a measured VPS
From $6.79/mo on a 2-year term. KVM on AMD EPYC, NVMe RAID10, ECC memory. No setup fee, cancel monthly.
30-day performance guarantee. Not satisfied? Full refund, no admin fee. How it works