---
title: "HTTP status checker, online and bulk | Logdash"
description: "Check the HTTP status code of any URL online, or of a whole list with one bash loop. Final code after redirects, response time, and alerts on change."
url: https://logdash.io/tools/http-status-checker
---

# 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

```bash
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.com
```

That 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

 check-urls.sh 

```bash
# 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.txt
```

Each 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

1. **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.
2. **Pick the interval** Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro.
3. **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.

### What does an HTTP status checker do? 

It requests a URL and reports the status code the server sends back, plus usually the redirects and the time taken. This one sends a GET from Logdash, follows up to 5 redirects and shows the final code.

### Is there a bulk HTTP status checker? 

For a list of URLs, use the bash loop above: it reads urls.txt and prints the code, redirect count and time for each line. httpstatus.io does up to 100 URLs at once in the browser. Logdash watches one URL per monitor.

### Is there a free HTTP status code checker online? 

Yes, the checker on this page. No signup to see the code. It keeps checking every 5 minutes for 24 hours, and a free account keeps it running with Telegram alerts.

### How do I check the HTTP status of a URL from the command line? 

curl -s -o /dev/null -w '%{http\_code}' followed by the URL prints the code alone. Add -L to follow redirects and -m 10 to give up after 10 seconds, the same rules the Logdash check uses.

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

[Website response time checker](https://logdash.io/tools/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.

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

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