Works for us, not for the customer: finding the cause

What “doesn’t work” means in a support case

“Doesn’t work” is not an error message but a summary. Very different pictures from different layers between browser and server hide behind it. Knowing the exact wording of the message saves most of the search.

Four follow-up questions usually narrow the case down:

• Wording and screenshot: the exact browser message.
• Device and browser: Does the error also occur in a private window or in another browser?
• Network: office Wi-Fi, home connection, mobile data or VPN? Does anything change on mobile data?
• Timing and scope: Since when, only this site or others too, one subpage or the whole domain?

The network question is the most valuable one. If the site works on mobile data and fails on the company Wi-Fi, the cause most likely lies with that network’s resolver, filter or proxy. If it fails everywhere but only on one device, the browser or the operating system is more likely.

Step one: do the check nodes reach the site?

Your own office is not a neutral vantage point: it runs the same resolvers the developers use, there may still be an entry from the migration in the hosts file, and the browser has known the site for months. Before searching on the customer’s side, you therefore need a view from outside.

XICTRAQ® uptime monitoring checks every website from three nodes in Nuremberg, Helsinki and Falkenstein, which means two in Germany and one in Finland (XICTRAQ® feature page). An outage only counts as confirmed when two of three nodes report it (XICTRAQ® feature page). The website’s node-consensus panel shows the latest result per node with status, response time and location.

If the connection from a node already fails at the transport level, it reads “Unreachable from scan node (timeout/blocked)” with the concrete reason instead of a blanket “offline”. The uptime monitoring documentation explains how to read this node-level finding and when it turns into an incident.

The result sets the direction of the search:

• All nodes reach the site: The server and authoritative DNS respond, and the cause most likely lies on the way to the visitor or with the visitor.
• Two or three nodes fail: The consensus flips and an incident is opened. Continue with server, DNS and network.
• Only one node fails: The status stays green. The node-level finding shows whether that node has a local network problem or the target blocks data center addresses.

When the nodes fail: server, DNS or network

The timing waterfall shows how far the connection got: DNS resolution, TCP connection, TLS handshake and time to first byte (TTFB). The phase in which the measurement stops names the layer to search.

• Stops at DNS: deleted record, wrong delegation, expired domain or DNSSEC error. DNS monitoring makes changes to records and delegation visible.
• Stops at TCP: A timeout points more toward a firewall dropping packets, an immediate refusal toward a closed port or a stopped service.
• Stops at TLS: Certificate expired, wrong name or incomplete chain. A fallback is described in the article Switch certificate authority.
• Long TTFB or server error: The application responds too slowly or with a status in the 5xx class, which the server uses to indicate its own error (RFC 9110).

If the site fails only from some networks, routing can be the cause. How to detect and document such a partial outage is covered in BGP and RPKI: when your site is missing from some networks.

A short DNS outage can linger longer for individual visitors than in the monitoring. If a resolver answers with SERVFAIL because it cannot reach the authoritative servers, it may cache that answer, but for no longer than five minutes (RFC 2308). RFC 9520 requires resolution failures, including failed DNSSEC validation, to be cached for at least one second (RFC 9520) and keeps the upper limit of five minutes (RFC 9520). The time of the customer’s attempt therefore belongs next to the measurement series.

Negative cache: the stored “does not exist”

An often overlooked cause is a negative DNS answer in a cache. A new subdomain such as new.example.com is announced by email, and a recipient clicks before the record exists. Or the zone was briefly empty while switching DNS providers. The customer’s resolver receives NXDOMAIN, meaning “this name does not exist”, and remembers it. After the fix, the office sees the site while the customer still gets “server not found”.

How long this can last is governed by RFC 2308. The authoritative server attaches the zone’s SOA record to every negative answer. Its lifetime is the smaller of the MINIMUM field and the time to live (TTL) of the SOA, and a resolver may cache the negative answer for that long (RFC 2308). As a resolver’s own upper limit, the standard names one to three hours as a sensible default (RFC 2308), and values above one day have been found to be problematic (RFC 2308). The protocol itself would allow caching for up to 68 years (RFC 2308).

Two rules make the case sharper. Under RFC 8020, an NXDOMAIN applies to the denied name and to all names below it (RFC 8020): if a resolver has cached NXDOMAIN for client.example.com, it should also return NXDOMAIN for www.client.example.com. In zones with DNSSEC, validating resolvers may generate negative answers for whole ranges of names from cached NSEC or NSEC3 records (RFC 8198). Zone operators should therefore not expect a newly added name to work immediately (RFC 8198). For how long such answers stay valid, RFC 8198 refers to the three-hour limit from RFC 2308 (RFC 8198).

Whether a negative cache is involved shows up in dig, ideally on a machine in the customer’s network:

The first query shows status NXDOMAIN and, in the SOA line before IN, the remaining lifetime of the negative answer in seconds. The second reads the SOA record: the last field is MINIMUM, the number before IN is the TTL of the SOA. The smaller of the two values limits how long a mistake can linger.

In operations, this means creating records before a link is sent and planning migrations so that the zone does not lack the name at any point. A low MINIMUM shortens the aftereffect. Flushing the cache on their own computer only helps the customer if the computer itself holds the answer. If the router or the provider holds it, the only options are waiting or another network.

Resolver TTL and old addresses after a migration

The counterpart of the negative cache is the stored old address. After a change of server or provider, resolvers keep the previous A or AAAA record until its TTL expires. How to lower the TTL before a migration is covered in DNS propagation and multi-resolver monitoring.

For the support case, a comparison is often enough: the free DNS propagation tool queries several public resolvers at once. If all of them return the new address but the customer’s machine does not, their resolver is lagging. The comparison does not see the customer’s resolver itself.

Expired records are a special case. RFC 8767 allows resolvers to answer with old data after the TTL has expired if the authoritative servers cannot be reached. Such answers carry a short TTL, with 30 seconds recommended (RFC 8767). The standard suggests keeping expired records for one to three days (RFC 8767), and a resolver should generally cap TTL values at seven days (RFC 8767). If the new name servers fail during a migration, some visitors may therefore still get the old address.

Which resolver answers for the customer is an open question: the router, the provider, a company DNS or encrypted DNS in the browser. With DNS over HTTPS (DoH), the browser sends its queries over HTTPS to a resolver of its choice (RFC 8484). Flushing the operating system cache then usually changes nothing for the browser.

In the browser: service workers, redirects and HSTS

If the site works in a private window or in another browser, the cause lies in the browser’s stored state. Three mechanisms keep working even after a fix on the server.

Service workers

A service worker intercepts the site’s requests and can answer them from its own storage. Around one fifth of websites use service workers (HTTP Archive Web Almanac 2025). If an old service worker serves an outdated version or an empty shell, only the visitor with that state sees the error. Under the specification, a registration counts as stale when the last check for a new version was more than 86,400 seconds, or 24 hours, ago (W3C Service Workers). How to find such traps after a release is shown in Stale cache after deploy.

Stored redirects

A redirect with status 301 is heuristically cacheable (RFC 9110): without an explicit cache directive, a browser may store it and follow it later without asking. For responses with Last-Modified, RFC 9111 names a freshness of 10 percent of the time since the last change as a typical value (RFC 9111). If a domain briefly pointed to a maintenance page with a 301 during a rebuild, visitors with that entry keep landing there.

HSTS in the browser

HTTP Strict Transport Security (HSTS) tells the browser to load a domain only over HTTPS for the duration of max-age, and with includeSubDomains all subdomains as well. The standard illustrates this with an example of one year, about 31,536,000 seconds (RFC 6797), and that value is common on the web: the median max-age is 365 days (HTTP Archive Web Almanac 2025). The header is sent by 36 percent of pages visited on mobile (HTTP Archive Web Almanac 2025), and of the sites with HSTS, roughly 40 percent also protect their subdomains (HTTP Archive Web Almanac 2025).

One rule in RFC 6797 is decisive: failures in establishing a secure connection should be handled with no user recourse, and a dialog to proceed is not intended (RFC 6797). A customer who once visited example.com, which sends HSTS with includeSubDomains, can afterwards no longer reach test.example.com without a valid certificate, while colleagues without that entry can. Likewise, the browser blocks an HSTS domain when a company proxy breaks open TLS with a certificate that is not set up as trusted. More on this in HSTS preload: requirements and risks.

The visitor’s network: VPN, company filters, parental controls

A VPN moves the starting point of the traffic to another country or a data center and frequently brings its own resolvers. Geo blocks and rules against data center addresses then apply, and the DNS cache is a different one. The test is simple: turn the VPN off and reload the page.

Filters work just as quietly. Company proxies, school networks, the parental control feature in the router or a provider’s security DNS block domains by category, and a new or miscategorized domain can fall through. The visitor then sees NXDOMAIN, a block page or a certificate warning, because the block page is delivered under a different certificate.

A resolver can signal that it blocks on purpose through Extended DNS Errors (EDE). RFC 8914 defines, among others, code 15 “Blocked” for a block under an internal security policy of the resolver operator (RFC 8914), code 16 “Censored” for a block due to an external requirement (RFC 8914) and code 17 “Filtered” for filtering the user requested themselves (RFC 8914). Not every resolver sends these codes. If one does, dig shows them on a separate line labeled EDE.

As a rule, only the customer’s IT department or the filter provider can allow or recategorize the domain. A note with domain, time and the wording of the block page helps. Whether the customer’s line is stable is shown by the ping test: it measures latency, jitter and packet loss from the customer’s browser to the XICTRAQ® measurement server in Nuremberg, which tests the connection, not the website.

IPv6 path: when only one protocol version fails

If a domain has an AAAA record, devices with an IPv6 connection usually try IPv6 first. If that path is broken, for example by a firewall rule for IPv4 only or an AAAA record that still points to the old server after a migration, the result depends on the device. Clients with Happy Eyeballs version 2 wait only briefly for the IPv6 answer after the DNS returns the IPv4 answer, with 50 milliseconds recommended (RFC 8305), and start the next connection attempt after a default of 250 milliseconds (RFC 8305). They fall back to IPv4 quickly, and the error often goes unnoticed.

Older software and mobile networks that use only IPv6 internally with a translation to IPv4 (NAT64) often lack this way out. The office with a pure IPv4 connection sees the site, while the customer on the mobile network sees a timeout. Testing both protocol versions separately shows the difference:

How to monitor both protocol versions separately over time is covered in IPv6 reachability monitoring.

Geo-blocking and WAF: when the server itself refuses

Some blocks are set by the server or an upstream web application firewall (WAF), and the status reveals which kind. Status 403 means the server understood the request but refuses to fulfill it (RFC 9110). Status 451 stands for a refusal as a consequence of a legal demand (RFC 7725). Status 429 reports too many requests in a given amount of time (RFC 6585) and can use Retry-After to say when a new attempt makes sense.

Geo-blocking relies on databases that map IP addresses to countries, often coarsely and sometimes wrongly, as the article Visitors from Frankfurt? How IP locations really come about shows. A customer in Germany whose addresses are located elsewhere is then blocked too, as is one with a VPN exit abroad. The check nodes in Germany and Finland do not see blocks for other countries.

Conversely, some WAF rules block data center addresses. The nodes then report “Unreachable from scan node (timeout/blocked)” while real visitors load the site. The remedy is a firewall whitelist for monitoring. For a single blocked customer, the WAF log for the customer’s time and IP address is the fastest evidence.

Narrowing it down in a fixed order

First come the checks that work without the customer and rule out many causes at once, then the ones that require the customer to do something.

1. Record the symptom: wording, screenshot, device, browser, network and time.
2. Look at the check nodes: consensus, result per node and the DNS, TCP, TLS and TTFB phase times of the checks at the time of the report.
3. If an outage is confirmed: determine the phase in the waterfall and continue with server, DNS or network.
4. If the site is reachable, have the network switched: mobile data instead of Wi-Fi, VPN off.
5. Rule out browser state: private window or another browser.
6. Check DNS at the customer’s end: NXDOMAIN, SERVFAIL or an old address from their resolver, compared with public resolvers.
7. Test IPv4 and IPv6 separately: if only one protocol version fails, the AAAA record or the firewall is a suspect.
8. Read the server side: access and WAF logs for the customer’s time and address.

A short template helps with the follow-up questions. It asks for what cannot be determined remotely:

Subject: Your report “site does not load”

To help us narrow down the cause, please send us the following details:

1. What message does the browser show? A screenshot helps most.
2. Which address did you open, complete with subpage?
3. Which device and which browser?
4. Over which network: office Wi-Fi, home connection, mobile data or VPN?
5. Does the site open when you switch your phone from Wi-Fi to mobile data?
6. Does it open in a private window?
7. Since when has the problem existed, and when was your last attempt?

What monitoring contributes and where it ends

External monitoring does not replace a look at the customer’s computer. But it answers the first question with a timestamp: did the site work from outside at the time of the report, and if not, in which phase did it fail? That lets you answer the customer factually instead of both sides guessing.

Three building blocks help day to day. A public status page shows customers the current state before they call. How to set one up is described in Set up a status page. DNS monitoring records changes to the domain’s records with old and new values in the changelog. If the changelog shows that a record has disappeared, a negative cache on the visitors’ side is an obvious suspect. And checking from several locations, explained in Multi-location monitoring, separates a real outage from a network problem at a single vantage point.

Resolve support cases with measurements, not guesses

“It works for us” does not help the customer much, even if it is true. What helps is a statement backed by a measurement: the site was reachable from several networks at the time in question, so the cause most likely lies on the way to the customer, and this one test narrows it down. Uptime monitoring provides the result per node and the timing waterfall, on the free plan as well. The check intervals per plan are listed on the pricing page.