Uptime checks reference

Every fact about uptime checks in one place. To add a check, see Watch a website or port.

If you found CloudViewer-Check/1.0 in your logs

Requests with this header come from Vaicoa’s uptime checks:

User-Agent: CloudViewer-Check/1.0 (+https://cloudviewer.app/checks)

A user of the app sets up a check against one host to find out whether it answers from the public internet. The app watches infrastructure on Hetzner; the endpoint does not have to be at Hetzner.

What it sends	One GET request to one path, with no request body, no query string, no cookies, no credentials and no custom headers. A port check only opens a TCP connection. A certificate check only completes a TLS handshake.
How often	At most once a minute from each of two networks (every 5 minutes for a free account). A failed attempt is retried once after 5 seconds. At most three redirects are followed.
What is kept	The status code, the latency, whether the connection and certificate were valid, the certificate’s expiry date, and, if one is set, whether a short text appears in the first 64 KiB. The response body and headers are not stored or transmitted.
Platform ceiling	All checks pointed at one IP address together are capped at 60 requests a minute, counted across all teams.

To allow or block it, match the User-Agent header. The source IP addresses are not published and can change, so an IP allow list or block list does not work. A blocked request shows as a failure to the team that set up the check.

If you did not expect these requests or want them to stop, write to support@mitjamartini.com with the host name and a time from your log.

Check types

App	Portal	What it does	Needs
Web endpoint	HTTP(S) endpoint	One GET request to a path. Passes when the status code is accepted and, if set, the response contains the text. On https it also records when the certificate expires.	host; port optional (443 for https, 80 for http)
Port reachable	TCP port	Opens a TCP connection. For services that do not speak HTTP, such as a database, mail or SSH port.	host and port
Certificate	TLS certificate	Completes a TLS handshake (TLS 1.2 or newer) and records how many days the certificate has left. Separate from the web check because certificates are also used on ports that do not speak HTTP, such as 993, 5432 or a gRPC service.	host and port

Every type records latency and an uptime percentage.

Options

Option	App	Portal	Default	Accepted values
Host (Hostname / Host)	yes	yes	—	a hostname or IP address, up to 253 characters; no scheme, port, path or credentials
Port	yes	yes	from the scheme for a web endpoint	1–65535; required for a port or certificate check
Scheme	yes	yes	https	https or http
Path	yes	yes	/	up to 256 characters; no query string or fragment; a missing leading / is added
Name	yes	yes	the hostname
Accepted status	no	yes	2xx	2xx, 2xx-3xx, or up to four codes such as 200,404; ranges such as 200-299 are refused
Response must contain	no	yes	none	plain text up to 64 characters, matched in the first 64 KiB; not a pattern
Latency budget (ms)	no	yes	none	a positive number; without a budget there are no latency alerts
Interval (seconds)	no	yes	60; free: 300	60–3600; fixed at 300 on a free account
Enabled	no	yes	on
Anchor to a resource (What are you checking?)	no	yes	external target	a server, dedicated server, load balancer, floating IP or primary IP of the team, or Something else on the internet
Edit an existing check	no	yes
Price and labels of a target	no	yes (Add price, Labels)	no price; counts as 0 in costs

The app form reminds you while you type a scheme, a port or a path into the hostname. Below its button it states your plan’s terms, and on a free account the Add check row shows how much of the allowance is used. A check added in the app is an external target.

Any check can be removed in the app (Remove check) or the portal (Remove). Removing the last check in the app also removes its target and frees the slot; in the portal the target stays until you remove it under Monitored Servers.

Where results appear

Place	What it shows
Dashboard	a check target is a row like any other: the dot is its current status, the strip one cell per day of history. A failing check is ranked next to your servers and from there reaches the widgets and Siri. There is no separate checks card
Resources → Uptime checks	every target you check, anchored and external, worst status first
Resource detail → Checks	for anchored checks, above the job reports: status dot, latency, uptime % and, for a certificate check, days remaining. Hidden when the resource has no checks
Check detail	the status and since when, the full target, the last error, status code and latency; a heartbeat bar, one cell per interval with the oldest on the left, over 24 hours, 7 days, 30 days or 90 days, with the uptime percentage for that range; From, one row per network with its latency or error; Certificate with the expiry date and Days left
Portal → Uptime Checks	every target with its checks, host, interval and an Edit and Remove per check

Statuses

Up	the endpoint responded as configured
Down	it did not, and the second network confirms it
Mixed	our two networks disagree. Shown on screen, never alerted
No data	neither network reported. Grey, never red

No data means Vaicoa has no result, not that your service is down. When our own network is unreachable, or a network has not reported within three check intervals, its result no longer counts. With no network reporting, the check turns grey, not red. It does not send an alert, and those minutes are excluded from the uptime percentage instead of counted as downtime. The heartbeat bar shows them in grey as well.

Two independent networks

Every check, on every plan, runs from two independent networks: one inside Hetzner and one outside it, at a different provider. A check is reported Down only when both agree. When they disagree, it is Mixed, which is shown on screen and does not send an alert. This prevents alerts caused by a network problem between one of our locations and your host, and a network outside Hetzner still sees your service when Hetzner’s own network has a bad day.

You don’t choose locations; every plan gets the same two networks.

One consequence: a service that is down from only one of the two networks (because of geo-blocking or a routing problem) shows as Mixed and does not send a push notification. The result is visible on screen.

Alerts

These alerts need Vaicoa Pro or Vaicoa Team. They use the same push notifications, muting and history as other alerts. On a free account, results are only shown in the app and the portal.

Alert (as the notification says it)	Severity	When
unreachable from outside	critical	both networks agree the check fails. It says “unreachable” rather than “down”, because it can appear next to a resource that Hetzner still reports as running
certificate expiring	warning	fewer than 14 days left
certificate expires imminently	critical	fewer than 3 days left
slower than its budget	warning	over the latency budget for 10 minutes; only when a budget is set

An alert is only sent after both networks agree and the alert rule has evaluated. A real outage reaches your phone within a few minutes, and a single failed probe does not send an alert. Thresholds and timings: Alert rules.

What counts against your plan

	Free account	Pro	Team
Check targets	4, a separate allowance	share the 20 monitored-server slots	share the 50 monitored-server slots
Checks per target	8, and at most 8 per team in total	8	8
Checked from two independent networks	yes	yes	yes
Interval	300 s, fixed	60–3600 s	60–3600 s
Check history	30 days	30 days	90 days
Alerts (push, email, alert targets)	no	yes	yes
Pause after 60 days without a visit	yes	no	no

On a paid plan, one limit covers everything Vaicoa monitors. A check on a server you already monitor uses no extra slot. Only a target that is not already a monitored server uses one: a load balancer, a floating IP or an external endpoint.

A free account has no monitored servers and no connected project, so its four targets are external endpoints you enter: a hostname, a port, a path. It can have 8 checks in total, spread across those targets in any way. The checks run and keep their history, but they do not send alerts.

When a paid plan ends, checks fall back to free terms: the oldest checks on the four oldest targets keep running, at most 8 of them, every 300 seconds, without alerts. The others stay configured but are not run, and nothing is deleted. Plan details: Plans and limits.

What a check sends

A check sends no request body, no custom headers, no cookies and no credentials. It only sends GET requests, and the path cannot contain a query string. The reasons:

• A check that sends nothing cannot be used to deliver data to a third party. It can only observe that something answered.
• Check URLs appear in shared briefs and coding-agent hand-offs and in answers from the Claude connector. A ?token=… would appear in all of them, so query strings are not allowed at all. For the same reason a host that contains credentials (token@host) is refused.
• The body match is a plain substring, not a pattern. It covers the common cases (ok, healthy, a version string) and cannot be used to run expressions on our servers.

For an endpoint that needs a credential, use a job report instead: one curl in a cron line, reported with the server’s agent token. The secret stays on your machine, and you get the same staleness alert as a backup job. See Watch an endpoint that needs a credential.

Response bodies and headers are never stored or transmitted. The substring is matched where the check runs, and only the result (match or no match) is sent back. Failures are recorded as one of a fixed set of reasons, never as free text.

A check makes at most one request a minute from each network and sends no payload, so it cannot be used as a scanner or a load test. Only check endpoints you are authorized to test.

Failure reasons

The app shows	Meaning
Name did not resolve	the DNS lookup failed
Connection refused	the host answered, but nothing accepts connections on that port
Timed out	no answer within the time limit
TLS handshake failed	the TLS connection could not be set up
Certificate expired	the certificate’s end date has passed
Certificate not trusted	the certificate chain is not trusted or does not match the host name
Unexpected status code	the HTTP status is not one of the accepted ones
Response did not match	the text was not found in the first 64 KiB
Too many redirects	more than three redirects
Address cannot be checked	the name resolves to a blocked address (see below)
Check could not run	the check failed on Vaicoa’s side, not on yours

Limits

• 8 checks per target. On a paid plan, a target uses one of your monitored-server slots. A free account has two limits of its own: four targets, and 8 checks in total across them. The second limit is the one that matters, because every check has its own hostname. A target is a way to group checks, not the thing being checked.
• Interval: 60 seconds minimum, 3600 s maximum, 60 s default. A free account runs at a fixed 300 s. A shorter interval is not available on any plan.
• Timeout: 10 seconds per attempt, of which at most 5 seconds to open the connection. A failed attempt is retried once after 5 seconds, so a single lost packet is not a failure.
• Host up to 253 characters. Path up to 256 characters, no query string. Substring up to 64 characters, matched in the first 64 KiB. At most four explicit status codes. At most three redirects, each checked against the blocked ranges again.
• 60 requests per minute against any one address, counted across all teams on the platform, and 600 per minute against one network (a /24 for IPv4, a /48 for IPv6). You only reach this by pointing many checks at the same host. The portal refuses a check that would go over, and says why.
• A free account’s checks pause after 60 days without a visit. If nobody on the team uses the app or the portal for 60 days, the checks stop running and the history shows that time as no data, not as downtime. Your next visit starts them again within a minute or two, and the app and the portal then say when the checks were paused and why, until that gap has left the 30-day history. Paid plans never pause.

Blocked addresses

A check cannot target an address in these ranges. The portal refuses it when you save, with the reason, and every connection is checked again immediately before it is made, including each redirect. A name that resolves to a public and a blocked address is refused as a whole. An IPv4 address written in IPv6 form is judged as the IPv4 address.

Range	Examples
Private	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, IPv6 unique local fc00::/7
Loopback	127.0.0.0/8, ::1
Link-local	169.254.0.0/16, fe80::/10
Cloud metadata service	169.254.169.254
Carrier-grade NAT	100.64.0.0/10
Tunnels and translation	6to4 2002::/16, Teredo 2001::/32, local-use NAT64 64:ff9b:1::/48
Documentation and benchmark	192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32, 198.18.0.0/15
Other special-purpose	multicast, broadcast, unspecified, reserved (240.0.0.0/4), 192.0.0.0/24, discard-only 100::/64
Vaicoa’s own network

To watch an internal endpoint, curl it from a cron job on a machine that can reach it and send the result as a job report.