Bulk Website Uptime Checker

Check whether up to 25 sites are currently online. Status code, response time, and a per-URL up/down verdict.

Bulk uptime checks are the fastest way to triage a 'something is broken' alert across a portfolio. Paste your sites, see who is down, escalate the right one.

## What this tool does

We send one HEAD request (falling back to GET if HEAD is blocked) to each URL and record the status code, response time, and any connection-level error. Anything that responds with 2xx or 3xx is up. Anything else is treated as a failure and gets a one-line reason.

## Use cases

Incident triage (is it just this site or my whole stack?). Pre-flight checks before a client demo. Post-deploy verification across a multi-tenant app. Health spot-checks during DNS or CDN migrations.

## Important caveat

A single 'up' from this tool is not a guarantee of continuous uptime — it is a single-point-in-time check. For real uptime monitoring with 1-minute intervals, multi-region checks, false-positive guards, and incident workflow, sign up for free LemWatch monitoring.

What this tool checks

• HTTP status code per URL
• Response time in milliseconds
• Up / down verdict (2xx or 3xx = up)
• DNS or connection-level errors
• TLS handshake failures

Why it matters

When a client reports "the site is down", the first question is "all of them?". Bulk uptime checks answer that in one paste so you triage in seconds, not minutes.

How to fix what it finds

• Any "Down" row needs an incident — open it in the single-URL diagnostic tool
• 5xx responses point at the origin server — start there
• 4xx responses (404, 410) point at routing or path issues — check recent deploys
• Timeouts point at DNS, certificate, or firewall problems — verify the domain resolves and HTTPS works

Methodology

For each URL we issue a HEAD request with a 10-second timeout. If the origin returns 405 Method Not Allowed (some servers do), we retry with GET. We follow up to 3 redirects. The 'up' verdict is true for HTTP 2xx and 3xx; everything else (4xx, 5xx, TCP errors, DNS errors, TLS errors, timeouts) is 'down' with a reason. Response time is measured from the moment we open the TCP connection to the moment we receive the response headers — not full body download time. We do NOT keep the connection open or run multiple samples in bulk mode; for that, use continuous LemWatch monitoring.

Frequently asked questions

Does a 200 response mean my site really works?

It means the homepage returned a 2xx status to a single bot request. It does not catch JS errors, broken checkouts, or missing images. For depth, use the single-URL Website Uptime Checker.

Why do some sites show "Down" here but work in my browser?

Common causes: WAF blocking unknown user-agents, geo-blocking (the check runs from our edge region), or the site only responds to GET (we retry with GET if HEAD fails).

Can this replace a monitoring service?

No. This is a one-shot snapshot. Real monitoring needs scheduling, multi-region verification, and alerting — that is what LemWatch is for.

What about TLS errors?

TLS failures (expired cert, hostname mismatch) are surfaced as down with a reason. Cross-reference with the Bulk SSL Checker for the full handshake details.

Does response time include TLS handshake?

Yes — we measure from connection open to response headers, which includes TLS negotiation.

Can I check IP addresses instead of domains?

You can paste any URL the underlying fetch supports, but DNS-based checks are recommended (most certs are bound to domain names).