Free Uptime Monitor – HTTP, Speed & TLS

An uptime check crosses DNS, connection, TLS, redirect, and HTTP layers

“Is the site up?” is not one test. The hostname must resolve, the network connection must open, TLS must negotiate for HTTPS, redirects must reach a safe final destination, and the application must return a usable status. This monitor records the final HTTP status, complete request time, redirect history, and certificate expiry. A fast 500 is still downtime; a deliberate 301 to the canonical HTTPS URL can be healthy.

Interpret HTTP status before treating a response as available

Result	Monitor state	Operational meaning
200–299	Up	The requested resource completed successfully.
300–399 with a valid destination	Up	The request redirects; review unexpected destinations or long chains.
401 or 403	Down for this public check	The endpoint is not publicly accessible from the monitor.
404 or 410	Down	The monitored path is missing even if the rest of the host works.
429	Down for this check	Rate limiting rejected the monitor and may also affect visitors.
500–599	Down	The application, origin, or upstream gateway failed.
No response	Down	DNS, connection, TLS, timeout, or routing failed before HTTP completed.

Monitor a meaningful path rather than an empty static file

A static health page can remain green while login, database queries, search, or checkout is broken. Choose a lightweight URL that exercises the dependencies required for the service's core promise, but does not create data or expose secrets. For a content site, a representative public article may be enough. For an application, provide a dedicated readiness endpoint that checks critical dependencies with strict timeouts.

Do not monitor an admin page that always returns 403 or a URL that deliberately redirects based on cookies. The monitor has no account session, so its result should model a new public visitor.

Response time is an external observation, not a full performance profile

The displayed milliseconds include DNS, connection setup, TLS, redirects, and the server response as observed from this monitoring host. It is useful for detecting a large change on the same URL over time. It is not Core Web Vitals, browser rendering time, or proof of worldwide latency. Cache state, network route, server load, and geographic distance can change a single sample.

Investigate a sustained rise rather than one spike. Compare application traces, database timing, CDN logs, and regional measurements before attributing the delay to code.

TLS expiry can cause an outage while the web server is still running

For HTTPS destinations, the check opens a verified TLS connection and reports days remaining on the presented certificate. Renewal automation should complete well before expiry. A valid date is not the only requirement: hostname mismatch, an incomplete certificate chain, an untrusted issuer, or an interception device can also stop negotiation and appear as a failed check.

If the site redirects between hostnames, inspect the certificate on every HTTPS hop. Monitoring only the final host can miss an expired certificate on the first URL that visitors enter.

Recurring checks build an incident timeline from state changes

Signed-in members can save three monitors. The scheduler looks for due monitors every five minutes, while each target is checked on a fifteen-minute interval. The stored row records the last state, status, response time, check time, and next due time. When site mail delivery is configured, a message is also sent when the state changes from up to down or from down to up.

At a fifteen-minute interval, a short outage can occur entirely between checks and the detection time can lag the actual failure. This free monitor is appropriate for personal sites and an independent secondary signal; business-critical services need shorter intervals, several regions, escalation rules, and retained incident history.

A single monitoring location cannot prove global availability

DNS responses, CDN routing, regional filtering, and network peering can differ around the world. A green result proves that this server reached the target at that moment. A red result proves that this path failed, but visitors elsewhere may still connect. Pair the check with origin logs, CDN analytics, synthetic transactions, and regional probes when the distinction matters.

Use this triage order after a downtime alert

1. Open the exact monitored URL from another network.
2. Use the DNS lookup to verify the hostname's live records and the SSL certificate checker to inspect validity and expiry before restarting the application.
3. Review the final status and redirect destination.
4. Inspect reverse-proxy, application, database, and queue health in that order.
5. Confirm recovery externally instead of relying only on a process status.
6. Record the root cause and change the health check if it failed to represent the incident.

Uptime monitoring questions for setting the right expectation

Why did the monitor miss a five-minute outage?

Checks run every fifteen minutes, so an outage that begins and ends between samples may not be observed. The interval is disclosed because this is a free availability monitor, not a continuous packet capture.

Will a slow page trigger a down alert?

A request that exceeds the configured timeout fails, but an ordinarily slow successful response remains up and displays its measured time. There is currently no user-defined latency threshold.

What information is stored?

One-off checks are not saved as content. When a signed-in user explicitly enables recurring monitoring, the target URL and latest operational state are stored so scheduled checks and change alerts can work.