How we measure

Every alert from You Up? says where the request stopped. It never says why, and it never guesses. This page explains what we measure, what we write about it, and what it costs you.

What every run records

A run is one request to your target from one of our locations. Each run times the four steps a visitor’s browser takes:

• The name. How long your domain took to resolve, and the address it resolved to.
• The connection. How long the TCP connection to that address took, and whether it went over IPv4 or IPv6.
• The secure connection. How long the TLS handshake took, and the certificate your server sent.
• The answer. How long the first byte of the answer took, the status code, and whether the page holds the text or JSON your check looks for.

When a run is slower than the threshold you set, the warning names the step that grew, compared with its usual time from that location: “slower: waiting for the answer”.

When something fails

A failed run stops at one of 7 places, always in the same order. Each one has its own sentence, in plain words. These are examples, with https://acme.com in place of yours:

• The name. “acme.com could not be found.”
• The path. “acme.com did not answer.”
• The connection. “acme.com refused the connection.”
• The secure connection. “acme.com’s certificate expired on 1 October 2026.”
• The answer. “acme.com answered with an error: 503.”
• The content. “The page at https://acme.com did not contain the text this check looks for.”
• Ours. “acme.com points to a private address (10.0.0.5), which we cannot reach from the internet.” When the stop is on our side, we say so.

Each sentence comes with at most one next step, such as “Check the DNS records for acme.com at your DNS provider” or “Send the report to your hosting provider”. When nothing is yours to change, the next step says that too.

The report for your hosting provider says the same thing in technical terms, and carries the addresses, routers and hops: “No answer came from 203.0.113.7 on port 443. A router at 198.51.100.1 (Example Transit, AS64500) was the last to answer, 4 hops out.” It is written for the network engineer who reads your support ticket.

The alert never waits. Your alert goes out as soon as our locations agree that the target is down, worded from what the failed run already saw. Only then do the failing locations look closer: which router answered, whether small packets get through where full-size ones do not, what each of your nameservers answers. What they find is added to the Incident and to the report for your hosting provider, in the technical terms, and the sentence you read stays as the run wrote it. It changes only when what they find changes what you should do: your DNSSEC signatures could not be checked, some of your nameservers did not answer, or your nameservers answered that the name does not exist.

The path trace

When a run never heard back from your address at all, no reply and no refusal, the question is how far the request got. To answer it, each failing location traces the path to your target once the Incident opens.

• It sends a TCP SYN to your own port, the same first packet a visitor sends. A firewall that lets your visitors in lets the trace through too. A ping check traces with ping.
• It keeps the same ports for the whole trace, so a load-balanced route is not mixed with another.
• It runs once per Incident per location, and sends at most 90 packets: 30 hops, 3 tries each. It stops as soon as your target answers, and gives up after 10 seconds.
• Each target gets at most one trace per location every 10 minutes, whoever asks.

For each hop it records the address that answered, the network that address is registered to and its AS number, and the round-trip times. The last router that answered “was the last to answer, 4 hops out”. Many routers pass traffic on without answering a trace, so a silent hop says nothing about your visitors.

The kernel’s view

The operating system keeps its own figures for every TCP connection. After each run we read two of them:

• Round trip. How long a packet takes to reach your target and come back, as the kernel measured it, and how much that time varies.
• Packets sent again. How many packets the kernel had to send a second time before your target acknowledged them.

These figures are what let a slow-answer warning tell the network’s share of the time apart from your server’s: the time to the first byte, minus one round trip, is roughly the time your server spent.

IPv4 and IPv6

When your domain has both IPv4 and IPv6 addresses, the run that decides up or down uses IPv4, so “down” and your uptime percentage keep one meaning. A domain with only IPv6 addresses is checked over IPv6.

About once every 10 minutes per location, after a passing run, we also try the other family. A target that answers over IPv4 and not over IPv6 can look healthy for days, and this is how it shows. When IPv6 alone fails and the failure is confirmed, you get a warning, not an Incident: most visitors still reach you, so no downtime is counted. The warning reads: “acme.com does not answer over IPv6 from Frankfurt and Helsinki. It answers over IPv4.”

When a run fails, we try the other family at once, and connect to each address your domain resolves to, up to 8 addresses. That is evidence on the Incident. It never decides whether you are down. Only locations whose own IPv6 works are asked about IPv6.

What we never write

A probe sees its own packets and what came back. It does not see your server, your load balancer or anybody’s routing table. So every sentence we write has to stay true whatever the cause turns out to be.

• No cause. We say what happened, never why. “The connection was refused” is true. To say that your server has stopped would be a guess: a firewall or a moved address refuses a connection just the same.
• No guess. We write what our locations saw, and nothing they did not. A sentence that hedges is not written at all.
• No finger-pointing. A network we name only answered, replied, or was the last to answer. We never say what it did with your packets. Where a guess would go, we write what we saw: “small packets got through; full-size ones did not”.
• No city. We never place a router in a city. Guessing a city from a router’s address goes wrong too often. The only cities we name are our own locations.

“acme.com is down” stays: it is the verdict our locations agreed on, in your own word.

What it costs you

Nothing. Every plan, Free included, gets all of it.

Most of it adds no traffic at all: the timings and the kernel’s figures come from the request each run already makes. What does reach your target:

• One request per run, from each location, at the interval you chose.
• One extra connection over the other address family, about once every 10 minutes per location, when your domain has both.
• When an Incident opens, from each failing location: a connection to each of your addresses, up to 8 addresses, a few DNS queries, and a path trace of at most 90 small packets, at most once every 10 minutes.