Free tool, no account required

Free Website Status Checker

Run one live availability check and retain an evidence sample for the submitted URL. Selected public-radar sites also show scheduled history.

Also known as: Uptime monitor, is it down

Evidence shown with sourceNo account requiredNo invented metrics

Website availability radar

A live board of selected sites, grouped by the latest measured server response. Every status comes from a stored server-side check; domains submitted by visitors are never published here.

506Sites

470Up

15Slow

21Down

Updated just now

Search & Big Tech

40 3 down

Cloud & Hosting

40 1 slow

Developer Tools

40 1 down1 slow

SaaS & Productivity

40 1 slow

Ecommerce & Retail

39 4 down1 slow

Finance & Fintech

40 1 down

40 3 slow

Media & News

39 2 down1 slow

Streaming & Entertainment

38 1 down1 slow

Email & Marketing

34 1 down

Travel & Hospitality

38 6 down

AI & Data

39 2 slow

Gov, Edu & Reference

39 2 down4 slow

No site matches your search.

Evidence model

Know what the result proves

This check proves whether one address answered one HTTP request at one moment, and which status class it returned. It is a point-in-time reachability result, not uptime: a site that is down for three minutes an hour will usually pass, and a site that answers here can still be failing for visitors on another network.

1. Source

Live server-side HTTP check. The result identifies where its evidence came from.

2. Boundary

Each result is one server-side request. It is not a global uptime SLA, browser performance test, or proof that every visitor can reach the site.

3. Next action

Use the finding to verify a problem, then connect a workspace when you need history, monitoring, or site-wide analysis.

Website monitoring explained

Keep a measured history of availability

A monitor is useful because one successful request is only a snapshot. Novaverb probes the sites on the public availability radar on a fixed schedule, so those carry a real sample pattern. For any other URL this page shows the check you just ran: we never republish a check somebody else made.

What the free monitor proves

Healthy - the final response was 2xx or 3xx.
Reached, needs review - the server replied with a 4xx client error.
Failed - the request received no response or ended with a 5xx server error.
For a site on the public radar, the pattern of our own scheduled samples.

What it does not prove

It is not a 24/7 global uptime SLA, a browser performance test or real-user monitoring. For scheduled checks, alerts, multi-location monitoring and long-term reports, connect the URL to a Novaverb workspace.

Each check is one request from Novaverb. A response proves that probe reached the server at that moment, not that every visitor could reach it.

Get the right answer

What to submit - and what to avoid

Submit the exact public address you want to reach. A private host is refused, and every redirect destination is checked again before it is requested. The free page keeps the submitted check as one evidence sample; scheduled monitoring and alerts belong to a connected workspace.

Use it like this

yourdomain.comAny public address form works. http or https, with or without www, a bare domain or a full path - we normalize it for you.

https://yourdomain.com/healthA stable public URL whose HTTP status reliably reflects up or down.

Avoid this

A page requiring loginAn authenticated page usually returns 401/403 to an anonymous probe, so it is reachable but needs review rather than healthy.

Expecting continuous uptime historyThis is one point-in-time check; ongoing monitoring is a connected-workspace feature.

Public methodology

Exactly how this result is produced

The address is requested once and the final response is classified consistently: 2xx or 3xx is healthy, 4xx proves the server replied but needs review, and no response or 5xx is a failed availability sample. The timestamp and final URL stay attached to that observation.

We request the exact public address through a pinned-IP safety check and re-check every redirect destination.
We classify 2xx/3xx as healthy, 4xx as reached but needing review, and no response or 5xx as failed.
We retain the submitted check as an evidence sample; scheduled monitoring and alerts are workspace features.

Built on public standards

The international standards this check applies

RFC 9110 defines HTTP semantics, including what each status class means, and the classification above follows it rather than a house interpretation. That is why a 301 is reported as reachable: the specification defines a redirect as a successful response that names another location, and calling it downtime would misreport the server.

IETFRFC 9110

HTTP Semantics - status codes

Reads the final status and distinguishes healthy 2xx/3xx, reviewable 4xx and failed 5xx responses.

Read the specification

We list a standard only where this tool genuinely reads or measures against it. Where a signal is outside a live check, the result says so instead of implying coverage.

Common questions

Website Monitor FAQ

What does the Novaverb Website Monitor check?

Each run sends one live HTTP request from Novaverb infrastructure and reports the HTTP status code, response time, and final URL after redirects, then stores a history of these measured checks over time.

Is this a guaranteed uptime SLA or monitoring service?

No. Each check is a single server-side HTTP request from one location. It indicates whether the site responded to that request; it is not a contractual uptime SLA or proof that every visitor everywhere can reach the site.

What do the HTTP status codes in the results mean?

A 200 means the request succeeded. A 3xx is a redirect (the final URL shows where it landed), 4xx indicates a client error like 404 not found, and 5xx signals a server-side error worth investigating immediately.

Why does the monitor show a different final URL than I entered?

Because it follows redirects and reports where the request ultimately resolved. If you entered an HTTP or non-www address, the final URL reveals your canonical HTTPS or www destination, which is useful for spotting redirect chains or loops.

What is a good response time in the monitor?

One request cannot establish a universal good threshold because distance, caching and page behavior differ. Compare repeated checks for the same URL from the same probe; a sustained rise is evidence worth investigating.

How is this monitor different from the performance or speed tests?

The monitor repeatedly records status, response time, and final URL to build an availability history. The performance and speed tests break one request into DNS, TCP, TLS, and TTFB stages for deeper diagnosis rather than ongoing tracking.

Does a passing check mean all my visitors can reach the site?

No. It confirms one location got a response at one moment. Regional network issues, DNS problems, or per-user routing could still block some visitors, so treat a passing check as a strong signal, not universal proof.

How often should I monitor my website?

Frequently enough to catch outages before customers do; many teams check every few minutes for critical sites. More frequent checks build a denser history, making it easier to correlate slowdowns and failures with deployments or traffic spikes.

What should I do when the monitor reports a 5xx error?

A 5xx means your server failed to fulfil the request. Check application logs, database connectivity, and recent deployments, and confirm the origin is running. Recurring 5xx responses in the history point to instability rather than a one-off blip.

Why does website availability matter for SEO?

A crawler can only process a page when its request succeeds. Repeated timeouts or server errors reduce successful retrieval; only that crawler's own reporting can confirm how a specific search engine experienced the site.

More free checks