Where a request stopped

Every Incident says where the request stopped. It never says why. You read it in three places, each with more detail than the one before: the sentence on the Incident card, each location’s block on the Events tab, and the report you copy for your hosting provider.

The examples on this page are for a Monitor that checks https://acme.com. Frankfurt and Helsinki sent it a request and heard nothing back. New York had its connection refused.

The sentence

The Incident card at the top of the Monitor’s page leads with one sentence, in plain words, about your own domain:

“acme.com did not answer.”

A request stops at one of 7 places, always met in the same order: the name, the path, the connection, the secure connection, the answer, the content, and ours. “Ours” is when the stop is on our side, such as an address we cannot reach from the internet. Then the sentence says so.

Under the sentence, the card names the other locations that stopped at the same place: “Helsinki saw the same.” A location that stopped somewhere else gets a line of its own: “New York: acme.com refused the connection.”

Below that is one next step. Here it is “Send the report to your hosting provider.”, with Copy report beside it. Other examples are “Check the DNS records for acme.com at your DNS provider.” and “Renew the certificate for acme.com.” When nothing is yours to change, the next step says that too: “Nothing for you to do.”

The alert goes out as soon as the locations agree, worded from what the failed requests already saw. Only then do the failing locations look closer. While they do, a quiet line under the sentence says “Checking the path from Frankfurt and Helsinki…”, with “More detail arrives within a minute.” What they find goes into each location’s block and into the report. The sentence changes only when what they find changes what you should do. How we measure says what they look at, and what it costs your server.

The same sentence is in every alert, in the Inbox, on the Events tab, and in the sentence field of every Webhook message. The Webhook’s detail field carries the same stop in detail: see the Payload reference.

Plain words and detail

The sentence is written for you. The rest of this page is about the detail, which is written for the network engineer who reads your support ticket. It uses their words, so here they are in plain words first:

An address (an IP address) is the number a domain name points to. A request goes to the address, not to the name. It is written like 203.0.113.7 over IPv4, or like 2001:db8::7 over IPv6.
A port is the door on that address the request knocks on: 443 for https, 80 for http, or the one you typed.
A network is the company an address is registered to. Each network has an AS number, the number networks are registered under: “Example Transit, AS64500”.
A router is a machine on the way that passes the request on to the next one.
A hop is one router along the way. “6 hops out” is the sixth router from our location.
A round trip is how long a packet took to reach a router or your address and come back.
TLS is the secure part of https. Before any page is sent, your server and our location exchange keys in a short exchange called the handshake.

So the same stop is said twice, once in each register. The card says “acme.com let us connect, but the secure (https) connection never finished.” and the detail says “203.0.113.7 accepted the connection, and the secure handshake never finished.”

Each location’s block

To see the detail, choose Open Incident on the card. The Events tab opens on the Monitor’s Incidents. Choose an Incident’s row to open it. At the top are the sentences, and Copy report beside them. Under them is one block for each location that failed, the location that saw it first at the top.

Each block has:

Its city and when its run started, as “Run started 14:49:00 UTC”. Every time on the dashboard is in UTC.
Its sentence in detail, with the address and the port: “No answer came from 203.0.113.7 on port 443.” In New York’s block: “203.0.113.7 refused the connection on port 443.”
acme.com’s address: the address that location connected to, or last tried, and the network it is registered to: “203.0.113.7 · Example Hosting (AS64501)”.
Timings: how long each step took, in milliseconds. An https Monitor has four: name, connection, secure connection and answer. A step that never finished shows what it heard, such as “no answer” or “refused”, or a dash when it never started.
Each address: when your domain points to more than one address, each one that location tried, over IPv4 or IPv6, and what came of it: “connected in” a time, “no answer” or “refused”.

A block says what came back, never why. A sentence on it would still be true whatever the cause turns out to be: a firewall, a moved address or a server that has stopped all refuse a connection the same way.

The path trace

When a location heard nothing at all from your address, no reply and no refusal, the useful question is how far the request got. So once the Incident opens, each such location traces the path to your address, once. Its routers fill the right side of that location’s block.

A quiet line over them says what a row is: one router between that city and your domain. Many routers never reply, which is normal. Each row has:

Hop: how many routers out it is.
Address: the router’s address, or “no answer” when it did not reply.
Network: the network that address is registered to.
Round trip: the time to that router and back.

The last router that replied is marked last to answer. A few silent rows past it are shown, then the list stops. When the trace reached your address, the list ends at your address and nothing is marked.

The detail sentence then grows: “No answer came from 203.0.113.7 on port 443. A router at 192.0.2.1 (Example Transit, AS64500) was the last to answer, 6 hops out.” That is only where the answers stopped coming. It does not say where the request went. A router that never replies to a trace still passes your visitors’ traffic on. We never place a router in a city: the only cities we name are our own locations.

How we measure says how the trace is taken, and how little it sends.

The report for your hosting provider

Copy report puts the report on your clipboard, as plain text, for you to paste into a support ticket with your hosting provider. It is on the Incident card, beside the next step when that step is to send it, and with the other buttons otherwise. It is at the top of the Incident’s row on the Events tab too. A Regional outage has its own, on its own row.

The report is written each time you copy it, from what the failing locations have found so far. It works from the moment the Incident opens, and copied a few minutes later it holds more.

It says, in the network engineer’s words:

what we checked, its addresses and their networks, and when it started failing, in UTC;
for each failing location, the address we sent from, the sentence in detail, its timings, and what the closer look found, with the path trace written out router by router;
the locations that reached your target at the same time, when some did;
the two headers every request of ours carries, so your host can find them in their logs;
one request: that the path be checked.

It never holds your Organization’s name, your other Monitors, or anything your server answered.

This is the report for the example on this page, as Copy report would copy it:

Report from uup about https://acme.com
Written 2026-10-09T14:55:00Z. All times are UTC.

Target: https://acme.com
Address: 203.0.113.7 (Example Hosting, AS64501)
Opened: 2026-10-09T14:49:14Z
First failed run: 2026-10-09T14:49:00Z
Closed: not yet

Failed from these locations:

Frankfurt, probing from 198.51.100.10 (Example Probes, AS64496)
  Run started: 2026-10-09T14:49:00Z
  No answer came from 203.0.113.7 on port 443. A router at 192.0.2.1 (Example Transit, AS64500) was the last to answer, 6 hops out.
  Timings: DNS 12 ms, total 10000 ms
  traceroute (TCP SYN to port 443) to 203.0.113.7:
    1  198.51.100.1  0.4 ms  0.4 ms  0.5 ms
    2  198.51.100.65  1.1 ms  1.2 ms  1.1 ms
    3  *  *  *
    4  192.0.2.33 (Example Transit, AS64500)  6.8 ms  6.9 ms  7 ms
    5  192.0.2.17 (Example Transit, AS64500)  9.2 ms  9.1 ms  9.3 ms
    6  192.0.2.1 (Example Transit, AS64500)  11.4 ms  11.6 ms  11.5 ms
    7  *  *  *

Helsinki, probing from 198.51.100.20 (Example Probes, AS64496)
  Run started: 2026-10-09T14:49:01Z
  No answer came from 203.0.113.7 on port 443.
  Timings: DNS 15 ms, total 10000 ms

New York, probing from 198.51.100.30 (Example Probes, AS64496)
  Run started: 2026-10-09T14:49:02Z
  203.0.113.7 refused the connection on port 443.
  Timings: DNS 9 ms

Our requests carry these headers:
  User-Agent: Mozilla/5.0 (compatible; uup/1.0; +https://uup.dev/probe)
  X-Uup-Check: chk_01K5XQ8F7H2M3N4P5Q6R7S8T9V

Please check the path to 203.0.113.7 from the networks above.