The tool page is tamperbox.dev/website-down-checker. It loads tamperbox.dev and waits for you to run a live check, says in one sentence whether the site answers from the probe’s location, and shows the stage where a request stopped. This page is the long version: what the request does, every rule that decides the verdict, what each outcome means, and how to fix and confirm each one.

Where processing happens: typing an address is read in your browser only. Nothing is sent until you press Check now or Enter. Then the Tamperbox server makes one request to the address, follows up to five redirects within ten seconds, and returns what it saw. Explicit result-action transfers use temporary browser storage; diagnostic results are not a monitoring history. Sample addresses on the reserved .example zone are answered in the browser from a fixture and never reach the network.

What the tool answers

Three questions, in the order a person with a broken site asks them:

1. Does it answer this probe? A successful request establishes reachability from the current server location. It cannot establish availability for every visitor or rule out regional, account-specific or intermittent failures.
2. If it is down, where does it stop? The name does not resolve, the connection or TLS handshake fails, nothing answers within ten seconds, the redirects never end, or the application answers with a server error.
3. If it is up, is it slow or answering with something other than the page? A total time over three seconds, or a 4xx status, are worth knowing even when the site counts as up.

The verdict answers the first question in one sentence. The Status section and its three stages answer the second. The findings and the Response table answer the third.

Inputs

A web address

Type example.com, www.example.com/status or a full address such as https://example.com/login. Without a scheme the address starts at https://. A path and query are kept and requested as written; a fragment (#section) is dropped because it never reaches a server.

The check is manual. Typing only says “Ready to check” and what will be requested; nothing leaves the browser until you press Check now or Enter. A sample address on .example is the exception: it is answered at once from the fixture because no request is made.

Refused before any request, with the reason in the field:

Input	Message
A space anywhere	A web address cannot contain spaces.
A scheme other than http or https	Use an http:// or https:// address, not ftp://.
mailto:, tel:, javascript:, data: or file:	Enter a web address, such as example.com or https://example.com/page.
A user name or password in the address	Remove the user name and password from the address. Heal it offers to remove them.
A port other than 80 or 443	Only the standard ports (80 and 443) are checked. Heal it offers the standard port.
An IP address	Enter a host name. Addresses written as IP numbers are not checked.
A single label such as intranet	Add the top-level domain, such as intranet.com.

Pasting and dropping

A pasted address is tidied before it is read: surrounding quotes and angle brackets are removed, as is trailing punctuation from a sentence. The tool takes the whole address, path included, because a page can be down while the home page works. Text that is not an address stays as pasted so the error above can explain it. Typing is never rewritten.

A .txt file dropped on the page or opened with Add a file is read in the browser, and its text goes into the field the same way.

Reading the result

Verdict and chips

The verdict is one of four sentences: “host is up.”, “host is up, but slow.”, “host is answering with errors.” or “Site unavailable:” followed by the reason. The line under it says whether this was a live check from our server or a sample answer. The chips are buttons: the first shows the status or the stage the request stopped at and scrolls to Status; the second shows the total time and scrolls to Response.

Under the chips, two items say where the input went: typing stays in the browser, and Check now means one request from our server.

Findings

Advice follows the observed outcome: DNS, connection, HTTP failure, timeout or slow response. Reachable results also show two notes for visitors who cannot open the site. The outcome is followed by a redirect finding when redirects occurred, a first-byte finding when timing is available, no request error occurred and the outcome is not slow, and the relevant visitor advice. Two or more passing findings are grouped under an expandable checks passed row; a single pass stays visible.

Status

One word (Up, Slow, Erroring or Down), the address requested with an arrow to the final address if the redirects moved it, and when the check ran. Under it, three stages in order: DNS, Connect / TLS and HTTP. The stage that failed is marked Failed; stages after it are marked Skipped, because the request never reached them.

Response

A table of what came back: the status, the recorded duration of the final hop, the total time (or the time until it failed), the number of redirects followed, and the final address (or the address tried).

History

History follows the current result evidence. Break it and Heal it record input changes, newest first. Revert restores the input before the latest recorded change; Reset input restores the input before the first retained change and clears the list. Restore input before this break under Heal it also reverts the latest change.

These actions reload and check the restored input. Restoring a public address can therefore send a new request, including on the two tools whose ordinary typing waits for a run button. Editing or pasting a new input clears History. The list lives in the current page; it is not saved monitoring data and does not restore an old network response.

Take it further

Only links with an available result value appear.

Follow-up	Value carried	When offered
TCP Ping	Final host and port	A live result without a DNS-stage failure
SSL Checker	Final host	No DNS-stage failure and the final scheme uses port 443
Website Hosting	Final host	No DNS-stage failure

Related checks and input transfer

Check the rest opens related tools without carrying input. Take it further carries the specific value listed above. Pasted file contents are not transferred through these links. Transfers temporarily use browser sessionStorage with a one-use random token in the URL fragment; the input itself is not in the URL. The destination accepts a transfer for less than one minute and removes the token. Manual destination tools wait for their run button or Enter.

Each destination collects new evidence. A follow-up link does not confirm the original verdict or repair the remote site.

Result cards

Six expandable cards below the result explain its meaning, give a beginner explanation, offer an agent prompt, describe good practice, suggest fixes and state limitations. Their text follows the current result; it is not another measurement. Open a card for its full explanation and the relevant Method or Guide. The agent prompt can be copied for review; copying it does not run a repair or send it to an agent.

Method

The page sends the address to /api/web/uptime. The server makes the request and the page judges the answer. Findings use these statuses:

Severity	Shown as	Meaning
Problem	FAIL	The probe could not retrieve a successful response
Warning	CHECK	The probe observed a slow response
Information	INFO	Interpret the response in its observed scope
Passed check	PASS	The observed response or final-hop timing met this check

The request

1. Address check. The server accepts HTTP and HTTPS addresses up to 2,048 characters, on port 80 or 443, without credentials. Anything else is refused before DNS.
2. DNS. The host’s A and AAAA records (RFC 1035, section 3.4.1; RFC 3596, section 2) are resolved over Cloudflare’s DNS-over-HTTPS JSON interface, following CNAME aliases. Both lookups must complete; an empty answer for one family is fine. A name that does not exist (RCODE 3, Name Error, RFC 1035, section 4.1.1), an inconclusive or truncated answer, a name with no address at all, and a name that resolves to any non-public address (the special-purpose ranges in the IANA registries, such as RFC 1918 private space) all stop here.

Connection, response and limits

3. Connection and TLS. The server opens the connection and, for https://, the TLS handshake (RFC 8446, section 4). The runtime that makes the request does not report TCP and TLS separately, so a refused port, a reset, an expired or wrong certificate and a failed handshake are all reported as one stage.
4. HTTP. A GET with the user agent Mozilla/5.0 (compatible; TamperboxBot/1.0; +https://tamperbox.dev/bot), Accept: */*, Accept-Encoding: identity, and no cookies. Redirects are not followed automatically: each 301, 302, 303, 307 or 308 is read, its Location (RFC 9110, section 10.2.2) resolved against the current address and checked like the first address, and the next request made. The body is never read; the run stops as soon as the final status and headers arrive.
5. Limits. At most six requests (five redirects), one ten-second budget for the whole run, DNS and redirects included. RFC 9110, section 15.4 leaves the redirect limit to the client (“A client SHOULD detect and intervene in cyclical redirections”); five is a stricter bound than most browsers, which allow around twenty, and can stop a legitimate but longer chain.

Times

Two times are measured on the server. First byte uses the final hop’s recorded duration, including its DNS validation and the wait for response headers. It is not a separately measured browser time to first byte. Total is the whole run, from before the first DNS lookup to the final status. A long redirect chain makes the total larger than the final page deserves; compare the two to see where time went.

The outcome

The following table summarizes how to interpret the observation. Its guide labels are not emitted finding IDs; the advice actually shown is listed in Finding reference.

Rule	Guide label	Interpretation	Verdict
The request stopped at DNS	dns	FAIL	Site unavailable
The request stopped connecting or in TLS	connect	FAIL	Site unavailable
The ten-second budget ran out	timeout	FAIL	Site unavailable
The redirects looped, exceeded five, had no Location, or pointed at a private address or another port	redirect	FAIL	Site unavailable
Status 500 or higher	http	FAIL	answering with errors
Status below 500, total time over 3,000 ms	slow	CHECK	up, but slow
Status 400 to 499	client	INFO	up
Status below 400	up	PASS	up

Why 500 is the line: RFC 9110, section 15.6 defines 5xx as “the server is aware that it has erred or is incapable of performing the requested method”, while a 4xx (section 15.5) is the server working and refusing this request. A 403 from a bot filter, a 404 for a moved page and a 429 rate limit (RFC 6585, section 4) all prove the site is reachable and answering. The status is shown so you can see whether it answered with the page.

Why three seconds: it is a judgment, not a standard. No RFC defines slow; three seconds is far above what a cached page or a healthy origin needs, so crossing it means something is worth looking at. The threshold applies to the total, so a site that is fast but redirects three times can cross it.

Stage placement

DNS, TCP and TLS timing fields are currently null. The stage panel derives its labels from a reported failure rather than measuring three independent phases. Policy failures can therefore be displayed under a broader stage label. Preserve the literal error code when diagnosing the cause.

The server reports a failure with a stage and a code. Stages map to the three columns as follows:

Server stage	Column marked Failed	Codes you may see
dns	DNS	dns_error, unsafe_target
connect	Connect / TLS	upstream_error and runtime connection errors
timeout	HTTP, “No answer in time”	timeout
http (redirects)	HTTP	redirect_loop, redirect_limit, redirect_unsafe, missing_location
none, status ≥ 500	HTTP, with the status

Standards and conformance

RFC 9110, HTTP Semantics

Implemented: status code classes (section 15) decide the outcome; redirection (section 15.4) with the five redirect codes and Location resolution as a URI reference against the current address (section 10.2.2); loop detection as section 15.4 asks of clients. Where it stops: a 303 is followed with GET, as all methods are GET here; Retry-After on a 503 or 429 (section 10.2.3) is not shown; the response body is not read, so a 200 page that says “maintenance” counts as up. RFC 9110 obsoletes RFC 7231, which older references cite for the same rules.

RFC 1035 and RFC 3596, DNS

Implemented on the server through DNS-over-HTTPS: A and AAAA queries, CNAME chains with a loop check, Name Error as non-existence. Stricter than a browser: both address families must resolve without error, and every address must be public. A browser that tries only IPv4 might reach a site this check calls down at DNS; the finding detail says which rule stopped it.

RFC 8446, TLS 1.3

The handshake is the runtime’s, with its trust store and SNI set to the host. The check does not report the protocol version, cipher or certificate; a TLS failure appears only as a Connect / TLS failure. For the certificate itself, use the SSL certificate checker, which opens a dedicated TLS probe and reports every certificate.

RFC 6585, status 429

Read as an answer from a working server: INFO, not down.

Finding reference

Advice emitted by the browser

These titles describe the reported outcome, not stable operation identifiers.

Title	Severity	Observed condition	Next check
The name does not resolve	FAIL	The probe reports a DNS-stage failure	Check authoritative records and another resolver; inspect the error code
Connection or TLS failed	FAIL	The runtime reports a connection-stage failure	Inspect the certificate, firewall, load balancer and listener
The server answers with an error	FAIL	The observed final status is 500 or higher	Compare application logs with the request time
No answer within 10 seconds	FAIL	A timeout or exhausted request budget	Read the literal error and final attempted address before diagnosing a timeout
Answered status	PASS / INFO	A non-slow response below 400 passes; a non-slow 4xx response is informational	Read the status before treating it as the page you wanted
Redirects could not be followed to the end	FAIL	An HTTP-stage error stopped the redirect chain	Read the recorded error and last attempted address
Followed n redirects	INFO	At least one redirect was followed	Inspect the final address and remove unnecessary hops
First byte after n ms	PASS / CHECK	No request error, a measured final-hop duration and a non-slow outcome; over 3,000 ms warns	Compare final-hop duration with total time
Up, but slow	CHECK	A reachable response took over 3,000 ms in total	Compare redirects and server processing with an independent client
If it will not open for you	INFO	The probe received a reachable response	Compare a browser, another network and any local proxy
If only some visitors see it down	INFO	The result is one observation from one place	Check independent locations and retain unavailable results

Evidence separate from advice

Status, redirect count, final address and recorded durations remain in the Status and Response panels as well as the applicable findings. Read these values together rather than treating a passing timing finding as proof of worldwide availability. A 4xx status still counts as reachable in this tool, even though it may represent a missing page, denied access or rate limiting. The total-time threshold does not measure how long the page takes to render in a browser.

An HTTP-stage error selects the redirect outcome; a budget error selects timeout. Other unrecognized error stages use the connection outcome while the Status panel retains the reported code. Use the literal code and attempted address as the diagnostic evidence. Do not infer that all visitors see the same failure from the wording of a headline.

Guide

It works here but not for me

The check reached the site from this server. Compare the failing client’s request, network and session before locating the cause.

1. Open the site on mobile data instead of your usual network. If it loads, compare DNS, routing, proxies and access policies on the failing network.
2. Turn off a VPN, proxy or ad blocker and reload.
3. Clear the DNS cache: restart the browser, or run sudo dscacheutil -flushcache (macOS), ipconfig /flushdns (Windows) or resolvectl flush-caches (Linux).
4. Compare what your resolver returns with a public one: dig +short example.com and dig +short example.com @1.1.1.1. Different answers point at a stale or filtering resolver.

The name does not resolve

1. At the registrar, check that the domain has not expired and is not on hold.
2. Check that the nameservers at the registrar are the ones that hold your records: dig +short NS example.com should list them.
3. Check that the exact host has an address: dig +short A www.example.com and dig +short AAAA www.example.com. A record for www does not cover the bare domain, and the reverse.
4. If the host resolves to a private address such as 10.0.0.5, it is reachable only inside your network. Publish a public address.

Confirm with the check again: DNS should be Passed.

Connection or TLS failed

1. Check the certificate with the SSL certificate checker or openssl s_client -connect example.com:443 -servername example.com </dev/null. An expired, self-signed or wrong-name certificate fails here.
2. Check the port is open from outside: nc -vz example.com 443, or use TCP Ping for the host and port, retaining unavailable-region results.
3. Check the server, load balancer and firewall are running and accept connections on port 443 (or 80).

Server errors

1. Read the application log for the time of the check.
2. A 502 or 504 comes from a proxy that got no good answer from the application behind it (RFC 9110, sections 15.6.3 and 15.6.5); check that the backend runs and listens where the proxy points.
3. A 503 (section 15.6.4) is often a maintenance switch or an overloaded pool; check whether it was deliberate.
4. Roll back the last deployment if the errors began with it.

Reproduce outside Tamperbox: curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' -L --max-redirs 5 --max-time 10 https://example.com/.

No answer in time

1. Check server load and whether the application accepts requests at all, for example with curl -v from the server itself.
2. Look for a firewall rule that drops traffic instead of rejecting it; drops look like timeouts.
3. Check from more than one region; a timeout only from some networks points at routing or a regional filter.

Redirects never end

1. Trace each hop with the redirect checker or curl -sIL --max-redirs 10 http://example.com/.
2. Look for two rules that undo each other: www to bare and bare to www, or http to https behind a proxy that tells the application the request was http.
3. Point the first address straight at the final https:// page, in one redirect.

Slow

1. Compare First byte with Total in Response. If First byte is most of the total, the final hop dominates; earlier hops account for the remainder. The final-hop duration includes DNS validation and connection setup, so it cannot isolate application processing.
2. Cache what does not change, and cut redirects to one.
3. Check again at a quiet hour to tell load from a constant cost.

Break it cases

Break it loads a case that shows each failure. A site cannot be made to fail on request, so these are sample hosts answered by a fixture; No such host is built from your own domain.

Case	What it loads	What to look at
Connection refused	down.harbor-supply.example	Connect / TLS Failed; Down
Certificate expired	expired.harbor-supply.example	Connect / TLS Failed, the certificate named in the message
Server errors (503)	error.harbor-supply.example	Erroring; HTTP Failed with 503
No answer in time	outage.harbor-supply.example	HTTP Failed, “No answer in time”
Slow to answer	slow.harbor-supply.example	Up, but slow; the time chip turns CHECK
No such host	nohost. plus your domain	DNS Failed

Break it replaces the field with an adapted input or a labelled fixture. Use History to Revert the latest change or Reset input to the starting input; restoring a live address runs a new check.

Worked example

The page loads tamperbox.dev in the field without sending a request. Press Check now to inspect https://tamperbox.dev/. The result is a live observation, so status codes, redirects and timings can change between runs.

Start with the returned status and observation time. An HTTP answer below 500 is classified as reachable, including 403 and 404; that does not mean the visitor received the intended content. Compare total time with time to the final response, then inspect the final address. The DNS, Connect / TLS and HTTP panels explain the reported failure stage, but they are not three independent tests.

To exercise failures without depending on a public outage, choose a reserved-domain Break it case. A fixture is labelled as a sample and does not contact that host. Replace the field with your own address to return to live mode and press Check now again. Compare another network or independent monitor before concluding that an outage affects everyone.

For agents

Use the Tamperbox MCP search tool to inspect the schema, then execute with tamperbox.request to call POST /v1/tools/website_down_checker. Supply the required url field as a full public HTTP or HTTPS URL. The operation is named website_down_checker; the browser page’s hyphenated identifier is not the API operation name.

The response contains regional observations, requested regions and unavailable-region details. Unconfigured regional probes are explicitly unavailable; one successful server observation does not establish global reachability.

Keep the input, observation time, source limitations and inconclusive results with any summary. Browser fixtures are demonstrations, not live MCP targets. Do not turn missing evidence into a passing check or infer that an inaccessible resource has been deleted.

See Connect an MCP client, Code mode and Security and privacy.

Limits

• One request, from one place, at one moment. Regional probing is not configured; the server reports the three regions it was asked for as unavailable.
• Any answer below 500 counts as up, including 403 and 404.
• Connection and TLS failures share one stage.
• The response body is not read, so a page that answers 200 with an error message counts as up.
• Only ports 80 and 443, only public addresses, at most five redirects and ten seconds.
• A site can block the TamperboxBot user agent while it works for people.
• Live checks are rate limited.
• Explicit result-action transfers use temporary browser storage; diagnostic results are not a monitoring history.

References

• RFC 9110, HTTP Semantics: section 10.2.2 Location, section 15.4 redirection, section 15.5 client errors, section 15.6 server errors. Obsoletes RFC 7231.
• RFC 6585, Additional HTTP Status Codes, section 4, 429 Too Many Requests.
• RFC 1035, Domain Names: Implementation and Specification, sections 3.4.1 and 4.1.1.
• RFC 3596, DNS Extensions to Support IPv6, section 2, the AAAA record.
• RFC 1918, Address Allocation for Private Internets, section 3, and the IANA IPv4 Special-Purpose Address Registry.
• RFC 8446, TLS 1.3, section 4, the handshake.