SecWeb
Log In Start Free Scan

Uptime Checker

Is your website online? Check HTTP status, real response time, DNS lookup, TLS handshake, server signals, and more — from a real network request in milliseconds.

Try:

What Is an Uptime Checker?

An uptime checker tests whether a website is currently online and reachable. Unlike monitoring services that ping your site every few minutes from many locations, this tool performs a single, real, real-time request — measuring every stage from DNS lookup to the last byte of the response.

It's useful for answering questions like:

  • Is my site down right now? — for a quick sanity check after user complaints
  • Why is my site slow? — the timing breakdown shows exactly which phase is the bottleneck
  • What HTTP status is my homepage returning? — critical for SEO troubleshooting
  • Is my SSL certificate valid? — quick expiry check
  • What server software is running? — visible via the Server header

Understanding the Timing Breakdown

Every HTTP request goes through up to five distinct phases. Each can become a bottleneck for a completely different reason.

DNS Lookup

The time to translate your domain name into an IP address. Slow DNS (over 300ms) is usually caused by a distant or overloaded DNS provider. Switching to Cloudflare DNS or Google DNS — both free — often cuts this from 200ms to under 30ms.

TCP Connect

The time to establish a TCP connection to the server. Dominated by physical distance (light through fiber travels at ~200,000 km/s — from London to Sydney is a hard 170ms minimum).

TLS Handshake

The cryptographic negotiation for HTTPS connections. TLS 1.3 completes in one round-trip; TLS 1.2 needs two. If you see over 500ms here, check whether TLS 1.3 is enabled on your server.

Server Wait (TTFB)

The time between sending the request and receiving the first byte of the response. This is a pure server-side metric. Under 200ms is excellent. Over 1 second indicates a performance problem in your application, database, or hosting.

Download

The time to transfer the response body. If this is high, either the page is huge or the connection is slow. Compression (gzip/Brotli) and CDN caching both help here.

HTTP Status Codes Explained

The HTTP status code is the server's response to your request. Here's what each class means:

  • 200 OK — everything is fine. The page is being served normally.
  • 301 / 302 — the page has moved. Your browser follows the redirect and shows the destination.
  • 304 Not Modified — cached version is still valid. Only appears with conditional requests.
  • 401 / 403 — authentication required or access forbidden. Usually means misconfiguration.
  • 404 Not Found — the page doesn't exist. On a homepage, this is a critical misconfiguration.
  • 500 Internal Server Error — the application crashed. Check PHP/Python/Ruby logs immediately.
  • 502 / 503 / 504 — the reverse proxy (Nginx, Cloudflare) can't reach the origin server. Usually a sign of server overload or downtime.

Why Response Time Matters

Page speed directly affects user behavior. Studies consistently show:

  • 53% of mobile users abandon sites that take longer than 3 seconds to load
  • Amazon calculated that 100ms of extra latency costs 1% of revenue
  • Google's Core Web Vitals treats 2.5 seconds as the "good" threshold for Largest Contentful Paint

When you check your uptime, treat the response time as equally important. A site that responds in 4 seconds is effectively half-offline from the user's perspective.

Uptime vs Monitoring — What's the Difference?

This tool is a manual, on-demand check. It answers the question "Is my site up right now?" — perfect for spot-checking after a deploy or when users complain.

An uptime monitoring service runs these checks automatically every 1–5 minutes from multiple geographic locations and alerts you the moment something breaks. That's a different product — usually paid — and worth having for anything mission-critical.

Use this tool for:

  • Verifying a fix worked after deploying
  • Diagnosing "slow right now" complaints
  • Checking if a third-party site is up
  • Testing a new server before switching DNS

How to Debug a Slow Response

Run the check, look at the timing breakdown, and match the slow phase to its likely cause:

  1. DNS slow — switch DNS providers (Cloudflare, Google, AWS Route 53)
  2. TCP connect slow — add a CDN or move to a closer data center
  3. TLS slow — enable TLS 1.3, disable legacy ciphers
  4. TTFB slow — enable server-side caching (Redis/Memcached), optimize database queries, use a PHP opcache
  5. Download slow — enable gzip/Brotli, optimize images, defer non-critical assets

Frequently Asked Questions

Uptime is binary — the site is either up (returns a valid HTTP status) or down (fails to respond, times out, or returns a 5xx error). Response time is the total elapsed time from sending the request to receiving the last byte. A site can be "up" but have a 4-second response time, which is effectively unusable for most visitors.
Common reasons: (1) Your host's firewall is blocking our scanner's IP; (2) Your site uses geographic blocking that excludes our location; (3) The request times out because your server is under load; (4) Your site is behind Cloudflare's "Under Attack" mode which blocks automated requests. Check your server logs for connection attempts from our scanner's User-Agent.
TTFB (Time To First Byte) measures how long the server takes to start sending data after receiving your request. It's a pure server-side metric — network latency doesn't affect it. A slow TTFB means your server is doing too much work per request (uncached database queries, heavy PHP, no opcache). Google recommends TTFB under 200ms for good performance.
No — this is a manual, on-demand tool. For continuous monitoring with alerts, you need a dedicated monitoring service like UptimeRobot, Better Stack, or Pingdom. They check from multiple geographic locations every 1–5 minutes and notify you via email, SMS, or Slack when something breaks.
A 200 status means the server successfully served the request, but slow loading can be caused by: slow server-side processing (high TTFB), large response size, lack of compression, or slow external resources. Check the timing breakdown — the phase that takes the longest tells you where to focus. For TTFB issues, look at caching and database optimization. For download issues, focus on compression and asset optimization.
Network conditions fluctuate. A 5–15% variance in response time between consecutive checks is completely normal — even for large sites. If you see swings larger than 30%, that indicates a real problem: server load spikes, database contention, or CDN routing issues. Run the check 3–4 times and look at the range, not just one result.
Yes — completely free. Guests can run 10 checks per hour; registered users get 60. Each check makes a real network request and consumes server resources, which is why there's a limit — but for typical use, you'll never hit it.
SecWeb Icon

Add SecWeb to your Home Screen

Get quick access to your security scans directly from your device.

Tap the Share icon below, then select "Add to Home Screen".