--- title: "Website response time checker | Logdash" description: "Check website response time from outside your network, then keep checking every 5 minutes. Plus the curl command that splits DNS, TLS and TTFB." url: https://logdash.io/tools/response-time-checker --- # Website response time checker Enter a URL and Logdash times a full GET request from its servers, from DNS lookup to the last byte, then repeats it every 5 minutes so you see a trend instead of one lucky number. The number Logdash shows is the whole request: DNS lookup, TCP connect, TLS handshake, the server thinking, the body downloading, and every redirect on the way. It is what a visitor waits for before the HTML arrives, not a lab score. One reading tells you little, because a single request can hit a cold cache or a noisy network. The checker keeps going every 5 minutes for 24 hours, so you see a line, not a dot. And compare like with like: a health endpoint at 90 ms and a homepage at 1.4 seconds can both be healthy, because they do different work. ## Check website response time from your terminal ```bash curl -sS -o /dev/null -w ' dns %{time_namelookup}s connect %{time_connect}s tls %{time_appconnect}s ttfb %{time_starttransfer}s total %{time_total}s status %{http_code} ' https://example.com ``` Every value counts from the start of the request, so subtract to get each phase. The gap from connect to tls is the TLS handshake. The gap from tls to ttfb is your server working, and that is the number your code controls. The gap from ttfb to total is the download. On plain HTTP the tls line reads 0\. Run it five times and take the middle value, never the first. ## Server response time checker: what counts as slow - Under 200 ms from ttfb minus tls: a cached page or a cheap API call. Most health endpoints should live here. - Up to 0.8 seconds to first byte: the line web.dev draws for a good TTFB. - Over a second of server time: a slow query, a cold start or a full connection pool. Fix it before it becomes an outage. - 10 seconds: the Logdash check gives up and records the site as down. - Large DNS or connect times: the problem is distance or DNS, not your code. A CDN fixes the first, a different DNS host the second. One honest limit. Logdash charts the response time of every check and alerts when a check fails, including when it takes longer than 10 seconds. There is no alert for slower than 800 ms yet, so a slow creep shows up on the chart, not in Telegram. The check also runs from one location, so the number includes the distance between Logdash and your server. That makes it a poor league table and a good baseline. Compare the line with itself: a jump from 180 ms to 900 ms after a deploy is the signal, wherever the check runs from. ### Logdash vs KeyCDN Performance Test | Feature | Logdash | KeyCDN Performance Test | | ----------------------------- | ------------------------------------------------ | --------------------------------------- | | Test locations | One | 10 around the world | | Timing breakdown | Total time only | DNS, connect, TLS and TTFB per location | | Price | Free | Free | | Repeats and keeps history | Every 5 minutes free, 15 seconds on Pro, charted | One-off test | | Alert when it stops answering | Telegram or webhook | Not part of the test | ### When KeyCDN Performance Test is the better pick - You want to know how fast the site is in Sydney and Frankfurt right now. Ten locations in one click beats one location every 5 minutes. - You are debugging a CDN or DNS setup and need the phase breakdown per region. ## Watch it for real 1. **Claim the check** Sign in with a free account and the response time chart you just watched keeps filling in. Five services on the free plan. 2. **Pick the interval** Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro. That is 288 data points a day at 5 minutes and 5,760 at 15 seconds, so shorter gaps mean a smoother chart and faster alerts. 3. **Connect Telegram and test it** Add a Telegram channel to the monitor, then stop the app. The next check fails, and a Telegram alert arrives saying the site is down with the status code or the timeout. ### What does a response time checker measure? The time from sending a request to receiving the full response. The Logdash checker measures one GET from its servers, DNS through the last byte, redirects included, and shows it in milliseconds. ### Is there a free website response time checker? Yes, this one. No signup to see the first number, then it checks every 5 minutes for 24 hours. A free account keeps it running with the chart and Telegram alerts. ### What is a good result on a server response time checker? Server time, ttfb minus tls in the curl output, under 200 ms for a cached page or a cheap API call. web.dev puts a good time to first byte at 0.8 seconds or less. ### How do I check website response time from the command line? Use curl with -w and the time\_namelookup, time\_connect, time\_appconnect, time\_starttransfer and time\_total variables, as in the snippet above. Run it several times and take the median. ## Keep reading [All free tools](https://logdash.io/tools): One page per tool, each with the tool itself, the command or formula behind it and a monitor that keeps checking after you leave. [Ping monitor online](https://logdash.io/tools/ping-monitor-online): Logdash does not send ICMP ping; it requests your URL over HTTP every 5 minutes for free, which answers what ping cannot: whether the site serves pages, not just whether the machine is switched on. [Uptime calculator](https://logdash.io/tools/uptime-calculator): The uptime calculator turns an uptime percentage into the downtime it allows per day, week, month, quarter and year, so 99.9% comes out as 1m 26.4s a day, 43m 49.8s a month and 8h 45m 57.6s a year. [99.9 uptime calculator](https://logdash.io/tools/99-9-uptime): At 99.9% uptime the calculator gives 1m 26.4s of allowed downtime per day, 10m 4.8s per week, 43m 49.8s per month, 2h 11m 29.4s per quarter and 8h 45m 57.6s per year. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.