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
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.comEvery 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
- 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.
- 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.
- 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.