Uptime Watchlist
Saved list of URLs with manual on-demand HEAD/GET probes and a rolling check history.
Overview
The uptime watchlist is a saved list of URLs you can probe on demand with HEAD or GET requests. Each probe records the response status, the response time, and a timestamp, building a rolling history per URL. There is no scheduled polling — you run the check when you want a fresh data point.
Solo developers monitoring side projects without a paid uptime service, small teams who want a quick visual on a dozen endpoints, and on-call engineers gathering evidence during an incident all benefit from a lightweight uptime checker. Long-tail keywords covered: manual uptime probe with history, lightweight alternative to UptimeRobot, and check website status with response time.
How it works
Each URL in the watchlist is configured with the probe method (HEAD by default, GET when the server does not support HEAD or when you want to download the body), a name, and optional notes. When you run a check, the server issues a request through the shared outbound HTTP client with a fixed timeout and records the status code and elapsed milliseconds. The result is appended to the URL's history, keeping the most recent N entries.
HEAD is preferred where supported because it returns the same headers as GET without transferring the body, making the probe lighter and faster. Some CDNs and misconfigured servers return different statuses for HEAD vs GET — switch to GET if you see suspicious mismatches.
Examples
https://example.comchecked every morning before standup → history shows 200s across the board, response times in the 60–80 ms range.- A staging endpoint that occasionally returns 502 → the history surface the intermittent failures clearly.
- A redirect chain
http://example.com→https://example.com→ final status 200; the watchlist records each terminal status. - An endpoint behind authentication will record a 401 every time, which is still useful as a "server is up" signal.
FAQ
Does it run automatic checks?
No. Probes only run when you click. For automatic checks, use a dedicated uptime monitoring service or schedule a cron job that hits your endpoints.
How much history is kept?
The most recent N probes per URL, where N is a small fixed cap. Old entries roll off as new ones arrive. Export the history if you need a permanent record.
Why does my probe show 200 but the site looks broken?
A successful response status just means the server returned something. The HTML or JSON inside could still be wrong. For content-level checks, GET the URL and inspect the body in the HTTP Request Tester.
Are private endpoints supported?
No. The shared HTTP client blocks loopback and RFC 1918 ranges to prevent SSRF. Probe internal endpoints from your own monitoring stack.