Skip to main content
Toollyz

Search tools

Search for a command to run...

Website Uptime Monitor

Add URLs to a watchlist; the tool fetches each one at your configured interval (5-3600s) from your own browser using `mode: no-cors`. Per-target uptime %, average round-trip, last status, and a colour-coded 240-check timeline. Targets and history persist in localStorage. 100% client-side — no Toollyz server in the middle.

What is the Website Uptime Monitor?

Website Uptime Monitor is an in-browser uptime tracker. Add URLs (with optional labels), set per-target polling intervals (5-3600 seconds) and timeouts. The tool fetches each URL with `mode: no-cors, cache: no-store` from your browser — this returns an opaque response, but that's enough to tell up (network success) vs down (network error) vs timeout (AbortController fired). The status code is intentionally invisible per CORS rules, but for an up/down monitor the opaque signal is what matters. Per-target stats: uptime % (last 240 checks), average round-trip latency (using performance.now), last status, and a colour-coded timeline strip showing every check in chronological order — emerald for up, rose for down, amber for timeout. All targets + history persist in localStorage so refreshing the tab doesn't reset (the actual polling does need an open tab; mobile browsers throttle background tabs aggressively). The 'Check now' button forces a poll across every target; 'Pause' stops the intervals.

How to use it

  1. Click Sample to load Cloudflare / Google / GitHub examples, or fill the form to add a custom URL.
  2. Click 'Start polling' — each target is checked immediately, then on its own interval.
  3. Watch the timeline strip fill from left to right.
  4. Hover any block in the timeline to see the timestamp and outcome.
  5. Click Pause to stop polling; click 'Check now' for a one-off check across all targets.

Benefits

  • Truly browser-side — no Toollyz server collecting data on your URLs.
  • Per-target polling intervals (5-3600s) and timeouts.
  • Up / down / timeout / blocked outcome states.
  • Average round-trip latency over the history.
  • 240-check rolling timeline with colour-coded blocks + hover tooltip.
  • Overall stat: cumulative uptime % across all targets.
  • Targets + history persist in localStorage.
  • `mode: no-cors` lets us probe any URL without CORS rejecting the request.
  • Honest disclosure about background-tab throttling and missing status codes.

Frequently asked questions

Why can't I see HTTP status codes?

`mode: no-cors` requests return an opaque response — the browser hides the status, headers, and body. We can detect network success vs failure vs timeout, but not 200 vs 404 vs 503. For full status visibility, use a server-side monitor (UptimeRobot, Pingdom, BetterUptime).

Why does this work without CORS configured on the target?

`mode: no-cors` says 'I don't care about reading the response' — the browser sends the request anyway and returns an opaque success/failure. CORS is about reading responses, not sending requests, so the target doesn't need to permit Toollyz.

Will it run when the tab is in the background?

Yes, but browsers throttle background tabs hard — intervals stretch (Chrome can hold to ~1s minimum, Safari and iOS may pause altogether). For reliable uninterrupted monitoring, keep the tab in the foreground or use a real uptime service.

What's the difference between 'down' and 'timeout'?

Down = fetch threw a network error (DNS fail, connection refused, TLS handshake fail, server hung up). Timeout = AbortController fired because the response didn't come within the per-target timeout (default 5s).

What's 'blocked'?

The URL isn't http(s) — we refuse to probe non-http schemes (file://, chrome-extension://, etc.) for safety.

How accurate is the latency?

performance.now provides sub-ms precision, but the opaque-fetch path goes through CORS preflight logic in some browsers, which adds overhead. The number is a good relative comparison but not a precise RTT benchmark. For real ping-style latency, see Ping Test.

Can I export the history?

Not in the UI yet — but the data is in localStorage under `toollyz:uptime-targets`. Open DevTools → Application → Local Storage to grab the JSON.

Why a 240-check cap?

Keeps localStorage small (each entry is ~30 bytes; 240 × 6 targets ≈ 50 KB) and the timeline strip readable on a single screen.

Does it alert me when something goes down?

No notifications — just visual indicators. For SMS / Slack / email alerts on downtime, use a server-side monitor.

Can I open the tool in multiple tabs?

Yes, but each tab runs its own polls (the timer state isn't shared). The localStorage data is shared, so the latest tab to write wins. Best to use one tab.

Is anything uploaded?

No. Every probe happens browser → target directly. Toollyz has no server.

Related tools

See all developer tools