HTTP status checker
Enter a URL and Logdash sends a GET request from its servers, follows up to 5 redirects and shows the final HTTP status code with the time the whole request took.
The checker sends one GET, not a HEAD, because plenty of frameworks answer HEAD with a 404 or 405 while GET works fine, and a checker that uses HEAD reports outages that do not exist. Redirects are followed up to 5 hops and the code you see is the final one. If nothing answers within 10 seconds, or the name does not resolve, the result is 0: no HTTP status at all. That is what a missing DNS record or a stopped load balancer looks like.
Check HTTP status of a URL
curl -s -o /dev/null -L --max-redirs 5 -m 10 \
-w '%{http_code} after %{num_redirects} redirects in %{time_total}s\n' \
https://example.comThat is the same request the checker makes. Drop -L to see the first hop instead of the last, which is how you confirm a 301 is really a 301 and not a 302 that search engines treat differently. A 000 means curl got no HTTP answer at all.
Bulk HTTP status checker
# urls.txt: one URL per line
while IFS= read -r url; do
[ -z "$url" ] && continue
result=$(curl -s -o /dev/null -L --max-redirs 5 -m 10 \
-w '%{http_code} %{num_redirects} %{time_total}' "$url")
printf '%s %s\n' "$result" "$url"
done < urls.txtEach line prints the final code, the number of redirects, the seconds taken and the URL. Pipe it into sort to group by code, or into grep -v "^200" to see only the problems. The URL goes through printf rather than the curl format string, so a percent sign in a query string cannot break the output. A thousand URLs at a second each is about 17 minutes, which is fine for a one-off audit after a migration.
Reading the codes
- 200: fine. A 200 on a page that should be gone is a soft 404, and search engines will keep it indexed.
- 301 and 308 are permanent, 302 and 307 temporary. Only visible without -L.
- 401 and 403: something refused the request. Often a WAF blocking non-browser clients, so check the same URL in a browser.
- 404 and 410: missing. 410 tells crawlers it is gone on purpose.
- 429: you are being rate limited. Slow the loop down.
- 500: the app crashed on this request. 502, 503 and 504: the proxy could not get an answer from the app.
- 000: no HTTP answer. DNS failure, refused connection or timeout.
Logdash vs httpstatus.io
| Feature | Logdash | httpstatus.io |
|---|---|---|
| URLs per run | One per monitor | Up to 100 at once |
| Redirect chain | Follows 5 hops, shows the final code | Every hop of up to 10, with headers |
| Status code and timing | Final code and total time | Codes and round-trip time per hop |
| Repeats on a schedule | Every 5 minutes free, 15 seconds on Pro | One-off checks |
| Alert when the code changes | Telegram or webhook | Not part of the checker |
When httpstatus.io is the better pick
- You are auditing a list of URLs after a migration and want 100 results in one table, exported to CSV or Google Sheets.
- You need every hop of a redirect chain with its headers. Logdash only keeps the final answer.
For uptime, the final code is the one that matters. A clean 301 that lands on a 500 is an outage, and a checker that stops at the first hop calls it fine. A chain longer than 5 hops is a bug in itself, so Logdash counts it as down rather than following it forever.
Get told when the code changes
- Keep the check Claim the dashboard with a free account. The URL you checked becomes a monitor, and every check stores the status code and response time.
- Pick the interval Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro.
- Connect Telegram and break it Add a Telegram channel to the monitor, then point it at a path that returns 404. On the next check a Telegram alert arrives naming the monitor as down, with the status code.