How do you tell whether a website is up for everyone?
Request it from several networks outside your own: if probes in different places get an HTTP answer — a 2xx or 3xx status in the sense of RFC 9110 — the site is up from there, and a failure only on your side points at your own connection, resolver or ISP. One round of requests is a snapshot; knowing that a site stays up needs monitoring, which repeats such probes on a schedule and alerts on failures.
How to use Website Uptime Checker
- Enter the website address (a bare host name such as example.com is read as https).
- Keep 3 probes for a quick answer, or choose 4 or 5; HEAD is the default method, GET if the server refuses HEAD.
- Press Check if it is up. The answer arrives within about 20 seconds.
- If the status is ✓ but you cannot open the site yourself, look at your own connection or DNS; if it is ✗ or ◐, read the probe errors.
Website Uptime Checker features
- Answers "is it up right now?" from outside your network: three to five Globalping community probes, picked by the network around the world, each send one request to your site
- A plain verdict — ✓ every probe got a 2xx or 3xx answer, ◐ some did, ✗ none did — with the number of probes up and the median response time
- Per probe: location, result, HTTP status code, total time and the address it reached; for a probe that got no answer, the error it reported
- Works for any public site, including those behind Cloudflare or another CDN
- One-time by design: no account, no schedule, no stored history — run it again whenever you want a fresh answer
Inputs and outputs
Inputs
- Website address: http:// or https:// URL of a public host; its path is requested, a query string is not sent.
- Probes: 3, 4 or 5. Method: HEAD (default) or GET.
Outputs
- Right now: the verdict symbol and what it means, probes up out of those that took part, the median response time of those up, and the HTTP status codes seen.
- Probe results: location, result symbol, status code, total time in milliseconds and the address reached, one row per probe.
- Probes without a response: the error each one reported. Measurement: Globalping measurement ID, status and the remaining quota.
Website Uptime Checker example
A site that answers from every probe (illustrative result)
Input:
Website address: https://www.example.com/ · Probes: 3 · Method: HEADOutput:
Status ✓ (every probe got a 2xx or 3xx answer) · Probes up 3 / 3 · Median response time 121 ms · HTTP status 200
Amsterdam, NL (EU) · ✓ · 200 · 64 ms
Dallas, US (NA) · ✓ · 200 · 121 ms
Tokyo, JP (AS) · ✓ · 200 · 233 ms
Note: This is a one-time check from a few Globalping probes: it does not monitor the site, keep a history or send alerts. Run it again to check again.How to read the Website Uptime Checker results
✓ — every probe that finished got a 2xx or 3xx answer: the site is up from those places at this moment.
◐ — some probes got a successful answer and others an error or nothing: a regional or intermittent problem, or one probe's own network. Run it again, or test the failing region with Website Availability by Region.
✗ — no probe got a successful answer. With 5xx codes the server is up but failing; with no response at all the site, its DNS or its hosting is unreachable. A 405 with HEAD only means the server refuses HEAD: switch to GET.
? — no probe finished in time. That is not a verdict on the site; run the check again.
When to use Website Uptime Checker
- Settle "is it down for everyone or just me?" when a site will not load on your computer.
- Confirm that a site is back after a deployment, a DNS change or an outage.
- Give support a quick, shareable outside view: status codes and times from several countries, with a public measurement ID.
Troubleshooting
- All probes show 405: the server refuses HEAD. Choose GET and run the check again.
- All probes show no response with a DNS error: the name does not resolve publicly — check the domain's DNS records and its registration.
- Probes up but your browser fails: flush your DNS cache, try another network or resolver, and check proxies, VPNs and firewalls on your side.
- "Measurements are limited to 30 per hour" or "hourly quota is used up": wait for the reset time shown.
Frequently asked questions about Website Uptime Checker
Does this monitor my website?
No. It is a one-time check: three to five probes each send one request when you press the button, and nothing is repeated, stored or alerted on. To know about downtime as it happens you need a monitoring service that checks every minute or so and notifies you; this page answers the question "is it up right now?".
Is the site down for everyone or just for me?
The probes sit on other people's networks around the world. If they get a 2xx or 3xx answer while your browser cannot open the site, the problem is on your side — your connection, your DNS resolver, a proxy or a firewall. If the probes also fail, the site or its hosting is the likely cause.
Why did one probe fail while the others succeeded?
The failing probe may be on a network with its own trouble, may reach a different CDN edge or server, or may resolve the name differently. Read its error, run the check again, and use Website Availability by Region to test that part of the world on purpose.
Why does a working site show 405?
The check sends HEAD by default, which some servers and frameworks refuse with 405 Method Not Allowed. The server did answer, so it is up; choose GET to see the status of a normal page request.
Are the checks private?
No. Globalping publishes every measurement, including the address tested and the results, to anyone with its ID. Mutqan stores nothing. Do not test addresses whose path is confidential.
Technical notes
Each probe sends one HTTP request — HEAD by default, GET on request, both as RFC 9110 defines them — for the path of the URL, over TLS for https. A 2xx or 3xx status counts as up (a redirect is an answer, reported with its 3xx status); 4xx and 5xx are answers that report an error; a request with no HTTP response at all (DNS failure, refused or timed-out connection, TLS error) counts as down for that probe.
No location is sent with the measurement, so Globalping picks the probes from its worldwide pool; they change from run to run. The Mutqan server creates the measurement, polls it for up to 20 seconds and returns what the probes reported, with the measurement ID.
Response time is the probe's total time for the exchange, which includes its own DNS lookup and connection set-up; the median of the probes that were up is shown so one slow probe does not dominate.
Limitations and methodology
This is not uptime monitoring: there is no schedule, no history, no uptime percentage and no alert. A short outage between two manual checks is never seen.
Three to five probes chosen by Globalping are a small sample; they may sit far from your users, and a probe's own network trouble can look like a failure of your site.
Only the HTTP answer to one request is measured — no page rendering, scripts, login or content check — and measurement parameters and results are public on Globalping.
Security and privacy
The host name and path go to the Mutqan server and to Globalping, which publishes the measurement; nothing is stored by Mutqan and no history is kept. Test only sites you are allowed to test.
References
- RFC 9110: HTTP SemanticsThe meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
- Globalping APIThe public API of the Globalping network: how ping, traceroute, MTR, DNS and HTTP measurements are created from community probes, located by country, region or network, and read back.
- Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google's SRE guidance on monitoring: black-box versus white-box monitoring and the four golden signals — latency, traffic, errors and saturation.