Open the zone → Health Checks tab in my.cubepath.com.

A health check probes one record's target and pulls its IP out of DNS when it stops responding, putting it back automatically when it recovers. That's the whole feature: no dashboard to watch, no alert to act on — the dead address simply stops being handed out.

Add a check

  1. 1
    Click Add health check
    The record picker lists the A and AAAA records that don't have a check yet.
  2. 2
    Name it
    Something you'll recognise in the list: api uptime, eu-west edge.
  3. 3
    Choose the type
    HTTPS (the default), HTTP, TCP or PING.
  4. 4
    Tune the timings
    Interval, timeout and the two thresholds. The defaults are sensible; read the table below before changing them.
  5. 5
    Save
    The check starts probing immediately and reports unknown until it has enough results.

Settings

SettingDefaultRangeNotes
TargetThe record's own value—A bare host or IP: no scheme, no path, no spaces. Override only to probe a different endpoint
Port—1–65535Required for TCP, optional for HTTP/HTTPS
Path/—HTTP/HTTPS only, must start with /
Expected status200100–599HTTP/HTTPS only. Anything else counts as a failure
Interval60 s10–3600How often we probe
Timeout5 s1–60Keep it well below the interval
Healthy after21–10Consecutive successes before the IP returns to DNS
Unhealthy after31–10Consecutive failures before it's pulled
EnabledOn—Turn a check off without deleting it. Billing stops while it's off

Choosing a check type

  • HTTPS/HTTP with a path is the only type that tells you the application is alive. Point it at a real health endpoint that touches what matters — if /health returns 200 while the database is down, the check is lying to you.
  • TCP proves a port accepts connections. Right for databases, message brokers and anything that isn't HTTP.
  • PING proves the host answers ICMP. It's the weakest signal: a machine can ping perfectly while every service on it is dead. Use it when nothing else is available.

Statuses

A check reports healthy (its IP is being served), unhealthy (it failed enough times in a row, its IP is not being served) or unknown (created too recently to have run enough probes). A disabled check shows as Disabled and doesn't affect DNS at all.

The list shows each check next to its record, the record's value and region, the target being probed and the interval — which is the view you want when several regional records each have their own check.

How fast failover actually is

Two delays add up, and only one of them is ours:

  1. Detection: unhealthy after × interval. With the defaults, three failures at 60 seconds is up to three minutes.
  2. Propagation: the record's TTL, because resolvers keep serving the answer they cached regardless of what we know.

Tightening the thresholds cuts detection time but makes the check twitchier: unhealthy after 1 will pull a server out of rotation over a single dropped packet. Two or three failures is the usual compromise.

Billing

Each health check is $10/month, prorated. Billing stops the moment you disable or delete it — deleting asks for confirmation and takes effect immediately.

Troubleshooting

SymptomLikely cause
The tab shows an upgrade noticeThe zone is on the Free plan; health checks need Pro or Business
The record isn't in the pickerIt isn't an A/AAAA record, or it already has a check
"A TCP check requires a port"Add the port
Target rejectedThe target must be a bare host or IP — strip https://, the path and any spaces
"Path must start with '/'"Add the leading slash
Status stuck on unknownNot enough probes have run yet; give it a few intervals
Unhealthy but the server is fineThe probe doesn't get through: a firewall blocking our probes, ICMP dropped, or an HTTP endpoint that returns something other than the expected status
The dead IP is still being servedDetection plus TTL hasn't elapsed yet, or the record's TTL is too high

For the wider picture of routing between regions and failing over inside them, see GeoDNS.