Website, TCP and heartbeat checks, run from outside our own network. In beta — it is days old, and the pricing is not set yet.
Your site, your API, your login page. We fetch it the way a stranger on the internet would, and record what came back.
Host and port. For the things that are not websites — a database, a mail server, a game server, an SSH daemon you would like to know had stopped answering.
You ping a URL on a schedule. If the ping stops arriving, we alarm. This is how you watch a backup job or a cron task, because the thing that fails is the thing that never ran.
Every monitoring service has two colours. Up and down, green and red. The problem with two colours is that a check which has quietly stopped working looks exactly like a check that is passing — and it looks that way right up until the morning you need it.
So ours has a third outcome. Before a probe reports anything, it establishes how its own traffic left the building. If it cannot show that it reached your target across the public internet, the result is recorded as not measured. Not green. Not red. Not measured.
This is not a hypothetical. Here are two probes of the same target, same code, same moment, from two of our own machines:
vantage=quorum-do egress=eth0 src=165.227.116.251 -> ok, 179ms, 200 vantage=ewr-transit-1 egress=wgcity src=10.99.3.1 -> unmeasurable
The second machine could reach the target. The probe would have come back green. It refuses to call it up, because its traffic left down an internal tunnel and never touched the public internet — so a green there would have meant we can reach you from inside our own network, which is not the question anyone is asking. It says so instead of guessing.
That distinction is the whole reason this exists, and it is the one we would want from a monitoring provider ourselves.
One missed check is a blip — a packet lost, a slow second. It takes two consecutive failures to mark a check down, and two consecutive successes to bring it back.
One email when it goes down. One when it recovers. Nothing in between, and nothing every five minutes while you are already awake and fixing it.
Checks run from a machine in New York that is deliberately not part of anything it measures. A box cannot confirm its own reachability, so we do not ask it to.
These are the numbers from a single end-to-end run on 20 September 2026, on a heartbeat check with a 60-second interval and a two-failure threshold. They are what happened that once — not a specification, and not an average, because one run is not a rate:
04:04:38Z pings stop 04:06:41Z one missed window -- still UP, deliberately 04:07:43Z two in a row -- DOWN, email sent 04:08:00Z pings resume 04:08:38Z two in a row good -- UP, recovery email sent
Three minutes and five seconds from the last ping to the alarm; thirty-eight seconds from recovery to the all-clear. A control check alongside it stayed up throughout, which is what tells you the run measured the target rather than the weather. Exactly two emails were sent for the two transitions.
Change the interval or the threshold and those numbers change with them. We would rather show you one run we actually watched than an average we assembled.
Some things are worth saying plainly, because the absence of them is usually the interesting part of a monitoring page.
This service is days old. Any figure we printed would be arithmetic on a window too short to mean anything, so there isn't one.
We are not going to promise a number we have not had long enough to keep.
Alerts send from our own mail relay, signed for tunnelnet.com, and we can show the receiving provider accepted them. Where a message lands after that — inbox, spam, a rule you wrote in 2019 — is not observable from the sending side, so we will not claim it.
The dashboard and the API sit behind our own login. If that login has an outage, you will not be able to reach the dashboard during it. Detection and alerting are deliberately built to survive that — the prober runs on its own credential and heartbeat ingest needs no login at all — so checks keep running and alerts keep sending even when the screen you would look at is unavailable. It is a real limitation and we would rather you heard it from us.
This is days old and has had exactly one user, who works here. It is deployed, it has caught and cleared a real outage end to end, and that is the honest extent of it. The price is not set, so nobody is being charged and no plan is being sold on this page.
If you want something watched while it is this new, get in touch and we will set it up with you rather than leave you alone with a form.