Monitoring Your Own Server From Another City

A monitoring agent running on the server it monitors cannot tell you the server is down. It is a small, obvious point that most small setups get wrong, and it is why the second cheapest machine you should ever buy is a watcher in a different city.

This is a practical layout for one or two servers: what to measure, what to alert on, where to put the watcher, and what it costs. Nothing here needs a managed monitoring product.

Four layers, in the order they pay off

External checks. Does the site answer, in how long, with the right status code, and is the certificate still valid. This layer catches the outages your customers would report, and it has to run somewhere else.
Host metrics. Processor, memory, disk space, disk latency, network. An exporter on each machine and a collector that scrapes it. Disk space alone justifies the whole exercise.
Application metrics. Queue depth, error rate, slow queries, worker health. The numbers that explain why the external check got slow.
Logs. Kept long enough to investigate yesterday, rotated hard enough not to fill the disk.

Layer one plus disk space alerting catches the majority of real incidents on a small estate. Build those first and resist the temptation to assemble dashboards nobody reads.

Put the watcher somewhere else

A probe in the same city as the thing it probes shares a fate with it. Our virtual machines run in five cities, so pair them deliberately.

Your server is in	Put the watcher in	Separation
Frankfurt	Amsterdam	3 ms, different facility operator and exchange
Amsterdam	Frankfurt	3 ms the other way
Vienna	Warsaw	Both under 7 ms from the hub, different regions
Warsaw	Vienna	As above, reversed
Bucharest	Frankfurt	10 ms, and the hub is unlikely to be down with it

If the watcher and the server share a city, your alerting is still better than nothing, it just cannot distinguish "the site is broken" from "the site is unreachable".

What a watcher costs

Less than most people expect, because probing is cheap. The work is a few requests a minute plus whatever history you keep.

Plan	RAM	SSD	Bucharest	Frankfurt or Vienna	Good for
Ion	2 GB	20 GB	€4.50	€6.00	External checks on a handful of endpoints, alerting, a status page
Pulse	4 GB	40 GB	€6.50	€9.50	The above plus a metrics collector with a few weeks of history
Core	8 GB	60 GB	€11.00	€17.00	Metrics, dashboards and a modest log store for several machines

Retention is a disk question, not a memory one. Extra disk comes in 50 GB units at €4 per unit per month, up to three units, which is usually cheaper than moving up two plans. Traffic is unmetered, so scraping every fifteen seconds forever costs nothing. Per city prices for the whole range are in our price by location breakdown.

What to alert on, and what to ignore

Every alert that fires without requiring action trains you to ignore the next one. A short list that earns its place:

The site did not answer twice in a row, from two locations. One failed probe from one place is usually the network, not the server.
Disk above 80 percent, and disk growth rate. The rate matters more than the level, because it tells you whether you have hours or weeks.
Certificate expiring within a fortnight. Renewals fail silently more often than anyone admits.
Memory pressure, and the out of memory killer firing. A process that was killed and restarted looks perfectly healthy afterwards, which is why an application that disappears under load is usually a memory problem rather than a connectivity one.
Silence. A job that should run hourly and has not run for three hours. Absence of activity is the hardest failure to notice and the easiest to alert on.
Backup did not complete. The alert you hope never matters, on the day it does. See automating backups.

Deliberately not on the list: processor above some percentage. A busy server is doing its job, and load that matters shows up as slow responses in layer one.

Where alerts should arrive

Somewhere you will see them outside working hours, and not only in email. Email is fine as a record and poor as an alarm. A chat channel, a push notification or a phone call depending on how much the outage costs. Whatever you choose, test it by breaking something on purpose once, because an untested alert path is the same as no alert path.

Using hourly machines around risky work

During a migration, a provider move or a large deploy, a second pair of eyes is worth having and does not need to be permanent. Every plan is available by the hour at the monthly price divided by 720 plus the location fee divided by 720. An Ion is €0.0063 an hour in Bucharest, so a probe box watching from a third city for a 12 hour maintenance window is eight cents.

Delete it afterwards, since a powered off machine still holds its disk and its address, and keep the permanent watcher on a monthly cycle because 720 hourly units cost exactly one month.

Where to start

Buy the smallest plan in a city your production is not in. Put external checks and alerting on it this week. Add host metrics next week. That order gives you the alerts that matter first, and the graphs that explain them second. Plans are on the VPS page, and if you already run a pair of servers, our note on pairing two locations covers the failover half of the same problem. The arithmetic behind how much downtime is worth preventing is in what the uptime nines actually cost.