Health checks: monitoring for websites, servers and services

With the IPv64.net health checks you monitor websites, APIs, servers, ports, certificates, DNS records, domains and cron jobs. Measurements run online from the IPv64 locations in Germany, locally in your home network with Node64, or both together (hybrid). This page lists all check types, settings, states and limits.

Overview: uptime monitoring at IPv64.net

A check tests a target at a fixed interval – for example whether a website answers with HTTP 200, a port is open or a certificate is still valid long enough. When the state changes, IPv64.net records an event, opens or closes an incident and notifies you through your notification channels. Every check can also serve as a monitor in DNS failover.

After logging in you find the health checks at ipv64.net/healthchecks2/, in the menu under Healthchecks → Healthchecks 2.0. A bar at the top of every page leads to the five areas (the interface is in German):

Everything the interface can do is also available through the health checks API (API v2).

Create a check

1. Open the form
   Click Neuer Check (new check) in the list.
2. Type, name and target
   Choose the check type, enter a name (up to 200 characters) and the target – depending on the type a URL, a host name, an IP address or a domain name. The hint below the field tells you what the type expects. The type's settings appear below.
3. Timing
   Interval, retry on failure, timeouts and IP version (see Timing and alerting).
4. Measuring points and evaluation
   Choose where the check runs (execution): online at IPv64, locally on nodes or hybrid – plus locations, measuring nodes and the rule for when the check counts as down.
5. Alerting
   Retries before alerting, stabilization, what you get notified about and through which channels. Without a selection your default channels apply.
6. Save
   The detail page opens. IPv64.net measures online checks right away; local and hybrid checks are picked up by the node as soon as it is connected.

The copy button on the detail page creates a new check with the same settings; its name gets the suffix “(Kopie)”.

Check types

There are eleven check types. Docker checks only run locally on a node, all others also online. The Proxmox checks that Node64 creates likewise run only on their node (more).

HTTP(S)

The HTTP check requests the URL and evaluates the status code.

Keyword

Like HTTP, but a keyword must also appear in the response. With darf NICHT vorkommen (must NOT appear) you invert the test – useful to detect error pages such as “maintenance mode”. The match is case-sensitive; the first MiB of the response is searched.

JSON (API)

Like HTTP, but the response must be valid JSON and meet up to 10 conditions – one per line in the form path operator value:

status == ok
queue < 100
items[0].up == true
tags contains web
version exists
name ~ ^web-[0-9]+$

Operators: ==, !=, <, <=, >, >= (numbers only), contains, !contains, ~ (regular expression), exists and !exists (without value). Write paths with dots and indexes, e.g. data.items[0].status. By default all conditions must be met; with Eine erfüllte Bedingung genügt (one condition is enough) a single one suffices. The value of the first condition appears in the message.

DNS

A DNS server in your home network and the expectation “node's public IP” only work locally on a node.

Ping (ICMP)

Sends several pings: packets 1 to 20 (default 3), max. loss in percent (default 0) and max. latency in milliseconds (0 = off).

TCP

Opens a TCP connection to the port. Optionally the check sends a text (e.g. EHLO x\r\n) and compares the beginning of the response (e.g. SSH-2.0). With the TLS handshake option it also tests TLS. Enter the port in the Port field; host:port in the target is taken over.

Port

Only tests whether the port is open. With Port geschlossen = OK (port closed = OK) you monitor that a port stays closed – for example that a database is not reachable from the internet.

Certificate

Reads the TLS certificate (port 443 unless set otherwise). Down if it is invalid, does not match the name or is valid for fewer than the minimum remaining days (default 14). Optional: server name (SNI), skip chain validation (private CA) and skip host name validation.

WHOIS / RDAP

Queries registration data: for a domain expiry, registrar, status and name servers; for an IP address, a network or an AS number (e.g. AS64496) network name, route, organization, country and city.

• Source: automatic (RDAP, otherwise WHOIS via port 43), RDAP only or WHOIS only.
• Domain: warn at remaining days: default 14, 0 = only at expiry.
• Expected details: up to 20 lines, as text or field: text with the fields registrar, nameserver, status, org, country, city, netname, cidr and asn. If one is missing, the check is down.
• WHOIS and RDAP servers limit queries. The interval is therefore at least 1 hour, the retry on failure at least 10 minutes.

Push / heartbeat

With a push check IPv64.net does not measure anything – your system reports in itself. If the report is missing for longer than the expected period plus grace, the check is down. Details under Push checks for cron jobs.

Docker container

Checks a container on a node: the target is the container's name or ID, the Docker host is optional (unix://, tcp:// or http(s)://; empty = the node's default). Docker checks only run locally on exactly one node – the one with the container – and cannot be moved. You set up monitoring of all containers of a host in Node64: Node64 docs: Docker.

Execution: online, local or hybrid

Under Messstellen und Bewertung (measuring points and evaluation) you decide who measures a check. Every location and every node is a separate measuring point with its own state. The server overview lists the servers of the locations with their addresses (e.g. for a firewall whitelist) and their state.

Local and hybrid become available once you have linked a node (see Link Node64).

Locations, nodes and evaluation rule

• Locations: Free accounts measure online from one location per check, all other account classes from both. Locked locations are marked “ab Supporter” (from Supporter) in the form.
• Measuring nodes: Several nodes can measure the same check, e.g. at different places or via VPN. Each node appears as its own measuring point.
• Down when … (policy): all measuring points report down (all, default), one measuring point reports down (any) or the majority reports down (majority, more than half). The form shows the rule for hybrid checks.
• Partially down: If only some measuring points report a problem and the rule does not apply, the check is “partially down” (degraded). You only get a message for it with the option to also notify on “teilweise gestört” (partially down).
• A measuring point only counts while its data is fresh: not older than three intervals, at least 5 minutes. A node also only counts while it is connected.

Private targets only locally

IPv64.net cannot reach your home network from outside. The form therefore rejects online and hybrid checks for private targets: private IPv4 ranges, 100.64.0.0/10, 169.254.0.0/16, loopback, IPv6 ULA (fc00::/7), link-local and site-local (fec0::/10) – also in IPv4-mapped notation such as ::ffff:10.0.0.1 – as well as names like localhost, *.local, *.localhost and *.internal. If a public name only resolves to a private or reserved address at measuring time, the online measurement is down with “target resolves to a private or reserved address”. Measure such targets locally with Node64.

Online, at most 30 seconds connect timeout and 60 seconds total timeout apply; longer values are shortened for the online measurement.

Diagnosis inside and outside

For hybrid checks the detail page compares the measuring points of your nodes (inside) with those of IPv64 (outside):

Moving: change the execution with a test run

You switch an existing check with Umhängen (move) on the detail page or as a bulk action in the list – or you change the execution in the form; then moving starts by itself after saving.

1. Choose the target
   New execution, measuring nodes and locations.
2. Test run
   IPv64.net measures the check once from every chosen location, every chosen node measures it once locally. The page shows the result per measuring point.
3. Takeover
   Only when all measuring points report OK is the new execution applied (“übernommen”). If one fails, everything stays as before. The token and the measurement history are always kept.

• Nodes in a test run must be online, and their remote management must not be “off”.
• If a measuring point does not answer within 60 seconds, the test run ends with “keine Antwort” (no answer).
• If you switch a local check with an interval below 20 seconds to online or hybrid, IPv64.net sets the interval to 20 seconds.
• Docker checks cannot be moved.

Timing and alerting

Which messages exist and how quiet hours, grouped alerts and reminders work is explained under Notifications.

Limits: measuring points and daily quota

Two limits of your account class apply to online measurement. Local measurements on your nodes never count against them.

• When the measuring point limit is reached, the form rejects further online measuring points (“Online-Limit erreicht”). Reduce the locations or measure locally on a node.
• Below the locations the form calculates how many online measurements the check needs per day (86400 ÷ interval × locations) and when the daily quota of the whole account will probably be reached.
• When the daily quota is reached, online measurements and the evaluation of pushes pause until midnight (Europe/Berlin). The checks then show “Kontingent aufgebraucht” (quota used up) and you get one message per day. Local measurements of the nodes continue. After an upgrade of your account class measuring resumes after about 30 seconds.
• The bar above the list shows the occupied measuring points, today's online measurements, your account class, the checks per execution and how many nodes are online.

States and reasons

For every failed measurement IPv64.net stores a reason, e.g. timeout, DNS error, connection refused, TLS error, wrong HTTP status, keyword missing, JSON condition not met, packet loss, latency too high, certificate expiring, domain expiring soon, push missing, push reports down or container stopped. The reason appears in the list below the state, on the detail page and in the messages.

Push checks for cron jobs and backups

A push check (heartbeat) monitors tasks that cannot be measured from outside: backups, cron jobs, scripts. Your system calls a URL after every successful run. If the call does not come, IPv64.net reports an outage.

After creating the check, the push URL is shown on the detail page in the Push-URLs box. It contains the check's token:

https://ipv64.net/health.php?token=YOUR_PUSH_TOKEN

• Without further parameters the call counts as “OK”. The response is OK.
• status=down (or fail) actively reports an outage, msg=… (or message=…) adds a short message (up to 500 characters).
• You can also send the token via POST in the field token or as the header Authorization: Bearer YOUR_PUSH_TOKEN.
• At most 60 pushes per minute per token; further ones are discarded.
• Pushes via this address count against the daily quota.
• If nodes measure the push check (too), IPv64.net forwards the push to all measuring nodes while they are connected. In your own network you can call the node's local address instead – http://NODE-ADDRESS:PORT/api/push/YOUR_PUSH_TOKEN; it also works without internet (see Node64 docs).

Examples with curl and cron

# Report success
curl -fsS -m 10 "https://ipv64.net/health.php?token=YOUR_PUSH_TOKEN"

# Report an outage with a message
curl -fsS -m 10 "https://ipv64.net/health.php?token=YOUR_PUSH_TOKEN&status=down&msg=backup+failed"

Backup every night at 02:30 – report success or failure (push check with an expected period of 86400 s and grace of 3600 s):

30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 "https://ipv64.net/health.php?token=YOUR_PUSH_TOKEN" >/dev/null || curl -fsS -m 10 "https://ipv64.net/health.php?token=YOUR_PUSH_TOKEN&status=down&msg=backup+failed" >/dev/null

The DynDNS update can trigger a push check as well: with &healthcheck=YOUR_PUSH_TOKEN on the update URL every update also sends a push. This way you notice when your router stops sending updates (see update URL).

List and detail page

List of checks

• Tiles at the top count the checks per state (OK, down, partially down, paused); a click filters the list.
• Filters: search by name, target and tag, plus state, type, execution, node, group and tag. Sorting by name, state, last changed, latency or type, ascending or descending.
• Each row shows the state with reason, name, execution, tags, target, type, current latency, the last 30 measurements of all measuring points as coloured bars (hover shows time, measuring point and reason) and since when the state applies.
• Bulk actions for selected checks: check now, pause, resume, move, add or remove a tag, delete.
• Check now (Jetzt prüfen) hands local and hybrid checks to their nodes immediately. Online checks are measured by IPv64.net at their interval; the next measurement follows shortly.
• Delete removes the check with all measurement data. Open incidents are closed, dependent checks lose the dependency.

Groups, tags and subgroups

• Group (up to 100 characters, e.g. “Home network” or “Websites”): checks with the same group appear together in the list. Every group can be collapsed and shows counters per state; the browser remembers what is collapsed.
• Subgroups: In the groups Proxmox VE and Docker that Node64 creates there is a separate, collapsible subgroup per Proxmox system or Docker host. If two systems have the same name (e.g. two clusters called “Cluster 1”), set the subgroup by hand in Node64 when editing the check.
• Tags: up to 20 keywords per check (up to 40 characters each), separated by comma or space. A click on a tag filters the list.

Dependencies

Under Abhängig von (depends on) you choose a parent check, for example your router for all devices behind it. While the parent check is down, the dependent one is not reported and shows “dependency down”. So an outage of your connection gives you one message instead of ten.

Detail page of a check

• Header with state, execution, type, remaining certificate lifetime (HTTP checks), tags and the buttons edit, copy, move, pause/resume, check now and delete.
• During an outage a notice with reason, message and start; for hybrid checks the diagnosis.
• The last 60 measurements as bars and a latency chart per measuring point for 6 h, 24 h, 7 days, 30 days or 1 year. Up to 24 h it shows single measurements, beyond that averages per hour or day. A click in the legend shows only one measuring point, Ctrl-click several.
• Availability across all measuring points for 24 hours, 30 days and 1 year.
• Measuring points with state, reason, latency and last measurement; push checks show the push URLs.
• Events (the last 50: down, OK again, partially down, flapping, reminder, not monitored …) with measuring point, reason, HTTP code and duration. “(ohne Alarm)” means that no message was sent for it.
• The last 20 incidents, the settings including the token and the raw last measurement with all details.

IPv64.net shows all times in the time zone you set under Notifications (default Europe/Berlin).

Maintenance windows and incidents

Maintenance windows

During a maintenance window IPv64.net sends no alerts; measurements continue. Under Wartungsfenster you create:

In the list you switch a window off and on again without deleting it; a running window is marked “läuft” (running). With Node64 linked, the windows also apply on your nodes.

Incidents

An incident starts when a check is down and ends with the recovery. The Störungen page lists all incidents of the last 7, 30, 90 or 365 days – optionally only the open ones – with check, start, end, duration, reason and the affected measuring points. At the top you see the number of open incidents and the total downtime in the period.

Found a mistake or missing something? Tell us in the v64.tech forum. · Updated: 2026-11-04