Validate the destination
Only public HTTP or HTTPS targets on standard ports are allowed; private and local addresses are blocked to prevent server-side request abuse.
Direct answer: A website uptime check records one bounded HTTP request from this server, including status, response time, redirect location and observation time—not a global uptime percentage.
The server makes one bounded request to the public URL, so the destination can observe this server's connection and request headers. Result responses are private, uncached and excluded from search indexing. Do not enter passwords or secrets. Read the lookup privacy policy.
What this website uptime check tells you
This on-demand check measures one HTTP transaction from this server. It validates that the hostname resolves only to public addresses, requests the entered URL without following redirects, and records the first response's status, redirect location, server header and total elapsed time.
- Whether this probe could resolve, connect and receive an HTTP response
- The first response status and Location header when it redirects
- How long the complete request took from this server
One request is not an uptime percentage; the website monitoring methodology explains repeated probes, assertions and alert thresholds.
If the response succeeds but its behavior is unexpected, use the response header inspection to check redirects, caching and browser policy signals.
How the evidence is collected
Request once
The probe does not follow redirects. It reports the first response and its Location header so the next destination is not contacted implicitly.
Timestamp the result
Availability changes quickly, so status and elapsed time are meaningful only with probe location and time context.
Read the fields without overclaiming
| Signal | What it can establish | What it does not prove |
|---|---|---|
| HTTP status | The server's response category for this request. | Complete application health. |
| Latency | Elapsed time observed by this probe. | Worldwide user experience. |
| Redirect | An HTTP instruction to request another URL. | That the final destination is safe. |
| TLS error | This client could not establish the expected secure connection. | That every client or region fails identically. |
The probe returns 503 in 180 ms
The endpoint was reachable and quickly returned Service Unavailable; this differs from a DNS or connection timeout. Check application and upstream health, retry from another region, and look for a Retry-After header before labeling the entire service globally down.
Common mistakes
- Calling one success 100% uptime
- Treating a fast error page as healthy
- Assuming a redirect destination was tested
- Comparing elapsed time without location, protocol and cache context
Website Uptime Check FAQ
Does 200 mean the page works?
It means the server returned a successful HTTP status. Content, scripts, APIs and user flows can still fail.
Why block private addresses?
A public diagnostic must not become a way to access internal services or cloud metadata from the server.
How should real monitoring differ?
Use repeated probes, multiple regions, defined assertions, consecutive-failure thresholds and recovery notifications.
Explore more website uptime check and domain research questions