Kiểm tra trạng thái website miễn phí

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.

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.

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.

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.

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.

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.

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.

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.

A 5xx means your server failed to fulfill 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.

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.