Website, TCP and heartbeat checks, run from outside our own network. $10 a month. In beta — it is days old.
Not taking new orders right now. We have paused new orders for TunnelNet Monitoring. Questions: support@minakilabs.com.
The price is $10 a month. We are not taking new orders right now. Questions: support@minakilabs.com.
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 outside our own network 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, so an outage there is an outage of the screen you would look at. Since 20 September that login runs on two machines behind a front door that fails over between them, so one of them dying no longer takes the dashboard with it — measured at about four seconds to switch. What it does not survive is the whole login host going away, because the name still points at one machine. We are telling you where the line is rather than calling it redundant and leaving you to find out.
And there is a case that switch cannot catch: a login node that stays up and keeps answering the health check, while being broken in some way the check does not look at. Nothing fails over automatically then, because from the outside it still looks healthy. That is the awkward one, so it is the one worth writing down.
Detection and alerting survive both cases by design: the prober runs on its own credential and heartbeat ingest needs no login at all, so checks keep running and alerts keep sending even while nobody can log in to look at them.
New orders paused right now.
SMS alerting, which is waiting on carrier registration and is sold separately under TunnelNet Alerting. A second probing vantage — today there is exactly one, so an outage at that single location is reported as a blind spot rather than guessed at. And a status page you can hand to your own customers. None of those are included, and none are charged for.
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 $10 a month; new orders are paused for now.
If you would rather we set the first checks up with you while this is new, get in touch — but the dashboard is there whenever you want it.