What our network actually did
Every number on this page is measured, from outside our network, by a machine that runs none of the things it is watching. We started measuring continuously on 2026-09-10, so the record is short. We would rather publish a short honest record than a long confident one.
Availability
Everything a customer needs in order to buy an address, sign in, enrol a machine or change their plan — fetched from outside our network, through both hubs, every 30 seconds.
| Since we started measuring | 99.965% (3m 30s down over 20,005 checks) plus 5m 53s when the watchdog was not running — not counted either way |
| Last 30 days | not published — the record does not cover this window yet plus 5m 53s when the watchdog was not running — not counted either way |
| Last 7 days | 99.9741% (2m 30s down over 19,327 checks) |
Computed from these 16 checks, all of
which must pass: auth.login, auth.oidc, auth.token, deep.write, io.checkout.ewr-1, io.checkout.mono-1, io.docs.ewr-1, io.docs.mono-1, io.healthz.ewr-1, io.healthz.mono-1, io.login.ewr-1, io.login.mono-1, io.root.ewr-1, io.root.mono-1, mesh.healthz.ewr-1, mesh.healthz.mono-1
The public site and its guides. It runs on a different machine at a different provider from the control plane, so it is measured separately — and it stays up when the control plane does not.
| Since we started measuring | 100% (0 seconds down over 20,005 checks) plus 5m 53s when the watchdog was not running — not counted either way |
| Last 30 days | not published — the record does not cover this window yet plus 5m 53s when the watchdog was not running — not counted either way |
| Last 7 days | 100% (0 seconds down over 19,327 checks) |
Computed from these 4 checks, all of
which must pass: com.guide, com.guides, com.pricing, com.root
Every incident, including the ones we caused
This is the complete list for the period above — not a selection. Two of the entries below are our own doing: a planned authentication change, and a drill in which we deliberately stopped the control plane to find out how long recovery takes. They are counted against us at full weight, because a customer sitting in front of the site during a drill has exactly the outage a customer sitting in front of it during a real fault does.
Sign-up, sign-in and the control plane
We shipped a release. The control plane restarts during a deploy and the site returned errors for about thirty seconds. Tunnels already up were unaffected -- they do not run through the control plane -- but signing in and buying did not work, so it is counted.
Failing: io.checkout.ewr-1, io.checkout.mono-1, io.docs.mono-1, io.healthz.ewr-1, io.healthz.mono-1, io.login.mono-1, io.root.ewr-1, mesh.healthz.ewr-1
A deliberate failure drill. We stopped the control plane on the leader on purpose to find out how long recovery takes and whether our alarms fire. The site returned errors for about a minute and a half. We publish drills as downtime because that is what they are.
Failing: deep.write, io.checkout.ewr-1, io.checkout.mono-1, io.docs.ewr-1, io.docs.mono-1, io.healthz.ewr-1, io.healthz.mono-1, io.login.ewr-1, io.login.mono-1, io.root.ewr-1, io.root.mono-1, mesh.healthz.ewr-1, mesh.healthz.mono-1
Both hubs stopped answering our watchdog for a single 30-second check and were fine on the next one. The database write probe in the same cycle succeeded, so this was not the control plane falling over. We have not established the cause, and we are not going to invent one; it is counted as downtime.
Failing: io.checkout.ewr-1, io.checkout.mono-1, io.docs.ewr-1, io.docs.mono-1, io.healthz.ewr-1, io.healthz.mono-1, io.login.ewr-1, io.login.mono-1, io.root.ewr-1, io.root.mono-1, mesh.healthz.ewr-1, mesh.healthz.mono-1
We were hardening the sign-in service and restarted it. Sign-in was unavailable for about a minute; addresses and tunnels already up were unaffected, because they do not go through sign-in.
Failing: auth.login, auth.oidc, auth.token
tunnelnet.com
No incident has been recorded on this surface since measurement began on 2026-09-10.
What we do not claim
There is no SLA today, and we are not going to imply one. An SLA is a refund promise, and a refund promise made on 8 days of measurement is a guess with money attached. We will offer one once we have six months of continuous measured operating history — that is 2027-03-10 at the earliest, and it is a date we will hold ourselves to on this page rather than in a sales conversation.
We do not claim 99.9% uptime. The figure above is what was measured over the window stated beside it, and a week is not a year. Ask us again when this page has twelve months on it.
This page does not measure your address. The watchdog measures our service — sign-up, sign-in, the control plane, the site — from the internet. It cannot see inside your tunnel, and it is not telling you whether your machine was reachable. We probe every enrolled address separately, but the current population is overwhelmingly our own lab equipment being switched on and off, so a fleet-wide reachability percentage from it would be a number about our laboratory wearing the clothes of a number about your service. We are not publishing one until it means something. status.minaki.io shows that per-address probing for what it is.
Hub failover is not instant, and one case is not automatic at all. Measured on 2026-09-16: when a hub fails completely and withdraws its routes, a tunnel carrying traffic is reachable again in about 25 seconds — the client re-handshakes at about 16 seconds and routing catches up by 25. An idle tunnel took 37 seconds, and failing back when the hub returned took about 50. If a hub stays up and announcing but stops forwarding, nothing fails over and it needs us to intervene. We are building a health-gated route withdrawal to close that case; until it ships, this is what the product does.
How this is measured
One sample every 30 seconds from outside our network. A surface is counted DOWN for a whole 30-second cycle if any of its checks failed in that cycle. Time when the watchdog was not running is subtracted from the window and reported separately as not-measured — never counted as up.
| Vantage | meshd-quorum-do — DigitalOcean, New York |
| Why there | Deliberately not on any machine it measures, and not on a control-plane node — a watcher that can be promoted to primary ends up watching itself. |
| Sample interval | 30 seconds |
| Measuring since | 2026-09-10 |
Time when the watchdog was not running is not counted as uptime. It is subtracted from the window and reported separately, because “we were not looking” and “it was working” are different facts and only one of them is evidence.
Some checks are deliberately excluded from the figures
above, because they measure our monitoring rather than our product:
meta.peer – our dead-men watching each other — internal, deep.jobs – scheduled jobs still committing — internal freshness, deep.synthetics – our own lab fleet reporting — internal, deep.status – our status feed answering — monitoring, not the product, status.page – status.minaki.io itself — monitoring, not the product, canary – exists only while a drill is running.
The raw record is at /uptime.json.
Record generated 2026-09-17 17:03Z — 3m 08s ago. Page written by
tnet-uptime-render 1.0.0 on the web host, which is a different
machine at a different provider from the control plane it reports on — so
this page stays up when that does not. If it is ever unreachable, that is
itself an answer.