Check HTTP status
Give it one address or a whole list and see the code each one answers with and how long it took: a 200 in 180 milliseconds next to a 404 or a slow 500, in one report. Useful for broken link audits. You pay per use, with no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
A broken link rarely announces itself; it just sits there returning a 404 or timing out while nobody is watching.
Why broken links go unnoticed
A broken link rarely announces itself. It just sits there returning a 404 or timing out while nobody is watching. Clicking through ten links is a five-minute task; doing the same for a sitemap of a thousand addresses, or for every outbound link on a resource page edited by different people over the years, is not something anyone does reliably by hand. Partner sites restructure, resources move and pages get taken down, and the only consistent way to catch it is to ask each address. Give the tool a list and it checks every address on its own, returning the code each one answered with and how long it took.
Reading the codes in one report
The families of codes have stayed stable for decades because they are useful: codes starting with 2 mean the page worked, 3 means it moved elsewhere, 4 means the problem lies in what was asked for, as with a deleted page, and 5 means the server broke while answering. A page that used to return 200 and now returns 500 under load is a different problem from one quietly returning 404, and lumping them together hides who needs to fix what. Teams scan whole sitemaps on a schedule, confirm that every old address still works after a migration, and keep directory links pointing at live pages.
The scale problem with checking links by hand
Clicking through ten links to confirm they load is a five-minute task; doing the same for a sitemap of a thousand URLs, or every outbound link in a resource page that gets edited by different people over time, is not something anyone does reliably by hand more than once. Links rot quietly — a partner site restructures, a resource moves, a page gets taken down — and the only way to catch it consistently is to actually ask.
What you can do with it
Sitemap and broken link audits
Scan an entire sitemap on a schedule to catch 404s and server errors before search engines or visitors find them first.
Content migration verification
After moving pages to a new platform, confirm every old URL either resolves correctly or redirects instead of dying quietly.
Resource and directory link hygiene
Periodically verify outbound links in a curated resource page or directory still point to live, responsive pages.
FAQ
How many URLs can I check in one batch?
Submit as many URLs as you need as individual async tasks; the model is built to scale from a single check to a full sitemap.
Is there a free plan?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
Am I billed if a check fails?
No. A failed task is retried automatically up to three times at no cost; only completed checks are billed.
What do the different families of codes mean?
Codes starting with 2 mean the page worked, 3 means it moved somewhere else, 4 means the problem lies in what was asked for, such as a deleted page, and 5 means the server broke while answering. Telling them apart shows which team needs to act.
Does it show how fast each page answered?
Yes. Next to each code you get how long the response took, so a 200 that took 180 milliseconds sits beside a 500 that took five seconds. You can sort the whole report by code or by speed.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/web/status \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com"}'const res = await fetch("https://api.kit.forhosting.com/web/status", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/status",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/status", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/status", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"url": "https://example.com"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.status",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
timeout_sec | 30 |
max_crawl_pages | 25 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This HTTP status checker API takes a list of URLs, requests each one, and reports back the status code and response latency for every single one, turning a manual click-through into a batch job you never have to remember to run.
What the endpoint returns for each URL
Send a list of URLs to POST /web/status and the task requests each one independently, returning the HTTP status code received and how long the response took, per URL, in a single structured result. That means you get a 200 with 180ms next to a 404 with no body and a 500 with a five-second delay, all in the same report, ready to filter and sort by code or by speed.
Why status codes are worth reading precisely
A page that used to return 200 and now returns 500 under load is a very different problem from one quietly returning 404 because it was deleted, and lumping them together as just 'broken' hides which team needs to fix what. The status code taxonomy has stayed remarkably stable since it was formalized decades ago precisely because the categories are useful: 2xx means it worked, 3xx means it moved somewhere else, 4xx means the request itself was the problem, 5xx means the server broke while handling it.
How it fits into ongoing monitoring
The batch nature of it means checking one URL or checking a thousand costs the same effort to set up. Because the check runs asynchronously and reports back by signed webhook, it is built to run on a schedule — nightly across a sitemap, hourly across a set of critical pages, or on demand right after a content migration — without a person babysitting a spreadsheet.
Reading latency alongside status
A 200 response is only half the story if it took six seconds to arrive; pairing status code with response time in the same report catches the slow degradation that precedes an outright outage, which a status-only check would miss entirely until it was already too late.
Integration use cases
Uptime spot checks
Check a set of critical endpoints on demand when something feels off, without standing up a full monitoring stack.
Technical questions
What does the HTTP status checker API return?
For each URL submitted, it returns the HTTP status code received and the response latency, delivered as one structured, signed result covering the full list.
Does it tell me if a URL redirects?
It reports the status code returned, including 3xx redirect codes; for the full hop-by-hop redirect path, the dedicated redirect chain checker goes deeper.
How do I get results back?
Via a signed webhook when the task completes, recommended for automated workflows, or a signed link valid for 24 hours.
What does each request cost?
$0.002 per request, one flat price whether the response is instant or times out.
Can I schedule this to run automatically?
Yes, trigger it from a cron job or pipeline on whatever schedule you need and let the signed webhook deliver results without manual polling.