HTTP Status Checker

HTTP Status Checker verifies whether URLs are live by sending HTTP HEAD requests and returning the status code, response time in milliseconds, redirect target, and server header for each URL in your list. Check hundreds or thousands of URLs at once for broken links, redirect chains, and server errors.

What does HTTP Status Checker do?

HTTP Status Checker takes a list of URLs and sends an HTTP HEAD request to each one. For every URL, it reports the HTTP status code (200, 301, 404, 500, etc.), response time in milliseconds, redirect target, content type, and server header. Results include boolean flags that make it easy to filter by category: OK (2xx), redirect (3xx), client error (4xx), or server error (5xx).

The actor processes URLs concurrently for fast batch checking. You can pass in dozens or tens of thousands of URLs and get a structured JSON, CSV, or Excel report showing the health status of each one. Failed requests (DNS errors, timeouts, unreachable hosts) are captured with an error message instead of silently dropped, so you always get a result for every URL you submit.

Who is it for?

• SEO specialists -- audit large websites for broken links, 404 pages, and unintended redirects that hurt search rankings
• DevOps and SRE engineers -- monitor endpoint availability across production services and APIs with scheduled runs
• Content managers -- verify that all links in published content, newsletters, or documentation are still active
• QA engineers -- validate that URL migrations and domain moves are complete by checking old URLs return proper redirects
• Web developers -- test API health checks and verify that endpoints respond with expected status codes
• Marketing teams -- check landing pages and campaign URLs before launch to avoid sending traffic to broken pages
• Affiliate managers -- monitor partner and referral links to catch broken or expired URLs before they cost revenue

Why use HTTP Status Checker?

• Comprehensive status reporting -- returns the numeric status code, human-readable status text, and boolean flags for OK, redirect, client error, and server error categories
• Response time measurement -- measures how long each URL takes to respond in milliseconds, helping you identify slow endpoints
• Redirect detection -- captures the redirect target URL from the Location header so you can verify where 301/302 redirects point
• Server and content type headers -- reports the server header (e.g., nginx, Apache, cloudflare) and content type for each URL
• Error capture -- URLs that fail due to DNS errors, timeouts, or connection refused get an error message instead of being silently skipped
• Batch processing -- check hundreds or thousands of URLs in a single run with concurrent requests
• Timestamp tracking -- each result includes an ISO 8601 timestamp so you can track when each URL was checked
• Ultra-low cost -- only $0.50 per 1,000 URLs checked, making large-scale audits affordable

What data can you get from HTTP Status Checker?

Every URL checked produces a result object with these fields:

Field	Type	Description
url	string	The URL that was checked
statusCode	number or null	HTTP status code (200, 301, 404, 500, etc.)
statusText	string	Human-readable status (e.g., "OK", "Not Found", "Moved Permanently")
isOk	boolean	True if status code is 2xx (success)
isRedirect	boolean	True if status code is 3xx (redirect)
isClientError	boolean	True if status code is 4xx (client error)
isServerError	boolean	True if status code is 5xx (server error)
redirectUrl	string or null	Redirect target URL for 3xx responses (from Location header)
contentType	string or null	Content-Type header value (e.g., "text/html", "application/json")
responseTimeMs	number or null	Response time in milliseconds
server	string or null	Server header value (e.g., "nginx", "cloudflare", "Apache")
error	string or null	Error message if the request failed entirely
checkedAt	string	ISO 8601 timestamp of when the check was performed

How much does it cost to check HTTP status codes?

HTTP Status Checker uses pay-per-event pricing. You pay a small start fee per run plus a per-URL fee for each URL checked.

Event	Price	Description
Start	$0.035	One-time fee per run
URL checked	$0.0005	Per URL checked

Example costs:

Number of URLs	Cost breakdown	Total
100 URLs	$0.035 + 100 x $0.0005	$0.085
500 URLs	$0.035 + 500 x $0.0005	$0.285
1,000 URLs	$0.035 + 1,000 x $0.0005	$0.535
5,000 URLs	$0.035 + 5,000 x $0.0005	$2.535
10,000 URLs	$0.035 + 10,000 x $0.0005	$5.035

There are no monthly fees or subscriptions. You only pay for what you use. Apify provides $5 of free platform credit each month, which covers checking approximately 9,900 URLs.

How to check HTTP status codes step by step

1. Go to HTTP Status Checker on Apify Store.
2. Click Try for free to open the actor input form.
3. Enter the URLs you want to check in the URL list. Each URL must include the protocol (http:// or https://).
4. Click Start to begin the run.
5. Wait for the run to complete. Progress is shown in the log panel.
6. Review the results in the Output tab. Each URL shows its status code, response time, and other details.
7. Download results as JSON, CSV, or Excel using the export buttons, or access them via the API.

For automated monitoring, use Apify Schedules to run the actor on a recurring basis (hourly, daily, weekly) and get notified when URLs go down.

Input parameters

Parameter	Type	Required	Default	Description
urls	array of strings	Yes	--	List of URLs to check HTTP status codes for. Must include the protocol (http:// or https://).

Example input:

{
    "urls": [
        "https://www.google.com",
        "https://en.wikipedia.org/wiki/Web_scraping",
        "https://example.com",
        "https://httpstat.us/404",
        "https://httpstat.us/301"
    ]
}

Output example

A successful 200 OK response:

{
    "url": "https://www.google.com",
    "statusCode": 200,
    "statusText": "OK",
    "isOk": true,
    "isRedirect": false,
    "isClientError": false,
    "isServerError": false,
    "redirectUrl": null,
    "contentType": "text/html; charset=ISO-8859-1",
    "responseTimeMs": 145,
    "server": "gws",
    "error": null,
    "checkedAt": "2026-03-01T12:00:00.000Z"
}

A 404 Not Found error:

{
    "url": "https://httpstat.us/404",
    "statusCode": 404,
    "statusText": "Not Found",
    "isOk": false,
    "isRedirect": false,
    "isClientError": true,
    "isServerError": false,
    "redirectUrl": null,
    "contentType": "text/plain",
    "responseTimeMs": 230,
    "server": "Microsoft-IIS/10.0",
    "error": null,
    "checkedAt": "2026-03-01T12:00:00.000Z"
}

A 301 redirect:

{
    "url": "https://httpstat.us/301",
    "statusCode": 301,
    "statusText": "Moved Permanently",
    "isOk": false,
    "isRedirect": true,
    "isClientError": false,
    "isServerError": false,
    "redirectUrl": "https://httpstat.us",
    "contentType": "text/html",
    "responseTimeMs": 180,
    "server": "Microsoft-IIS/10.0",
    "error": null,
    "checkedAt": "2026-03-01T12:00:00.000Z"
}

Tips and best practices

• Always include the protocol -- every URL must start with http:// or https://. The actor needs the full URL to make the HTTP request.
• Use for uptime monitoring -- schedule this actor to run every hour or every day with Apify Schedules to detect when URLs go down or start returning errors.
• Filter by status category -- use the boolean flags (isOk, isRedirect, isClientError, isServerError) to quickly categorize and filter results in your downstream pipeline.
• Monitor response times -- the responseTimeMs field helps identify slow endpoints that may need performance optimization or CDN caching.
• Combine with Redirect Chain Analyzer -- if you find redirects (3xx), use the Redirect Chain Analyzer to trace the full redirect chain and verify the final destination.
• Check before launching campaigns -- run this actor on all landing page URLs before launching email or ad campaigns to avoid sending traffic to broken pages.
• Export to Google Sheets -- use the Google Sheets integration to automatically push results to a spreadsheet for collaborative tracking and historical comparison.
• Set up webhook alerts -- configure a webhook to get notified via Slack, email, or your own endpoint when a run completes, so you can react quickly to detected issues.

Integrations

HTTP Status Checker works with all major integration platforms supported by Apify:

• Zapier -- trigger workflows when URLs return error status codes, send alerts to Slack or email
• Make (Integromat) -- build automated URL monitoring scenarios that run on a schedule and notify your team
• n8n -- create self-hosted automation workflows that check URL health and store results
• Google Sheets -- export results directly to a spreadsheet for collaborative tracking and historical comparison
• Slack -- get notified in a Slack channel when URLs go down or return unexpected status codes
• Webhooks -- receive HTTP POST notifications when a run completes, enabling custom integrations with any system

You can also chain this actor with the Redirect Chain Analyzer for deeper redirect analysis or the Broken Link Checker for crawling entire websites.

Using the Apify API

You can start HTTP Status Checker programmatically from your own applications using the Apify API. The following examples show how to run the actor and retrieve results.

Node.js

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: 'YOUR_TOKEN' });
const run = await client.actor('automation-lab/http-status-checker').call({
    urls: [
        'https://www.google.com',
        'https://httpstat.us/404',
        'https://httpstat.us/301',
    ],
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items);

Python

from apify_client import ApifyClient

client = ApifyClient('YOUR_TOKEN')
run = client.actor('automation-lab/http-status-checker').call(run_input={
    'urls': [
        'https://www.google.com',
        'https://httpstat.us/404',
        'https://httpstat.us/301',
    ],
})
items = client.dataset(run['defaultDatasetId']).list_items().items
print(items)

cURL

curl "https://api.apify.com/v2/acts/automation-lab~http-status-checker/runs" \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{
    "urls": [
        "https://www.google.com",
        "https://httpstat.us/404",
        "https://httpstat.us/301"
    ]
  }'

Use with AI agents via MCP

HTTP Status Checker is available as a tool for AI assistants via the Model Context Protocol (MCP). This lets AI agents check URL health as part of larger workflows.

Setup for Claude Code

$claude mcp add --transport http apify "https://mcp.apify.com?tools=automation-lab/http-status-checker"

Setup for Claude Desktop, Cursor, or VS Code

{
    "mcpServers": {
        "apify": {
            "url": "https://mcp.apify.com?tools=automation-lab/http-status-checker"
        }
    }
}

Example prompts

• "Check HTTP status codes for these 50 URLs and tell me which ones are broken"
• "Find which URLs return 404 errors from this list of landing pages"
• "Check these API endpoints and flag any that have response times over 500ms"

Learn more in the Apify MCP documentation.

Is it legal to check HTTP status codes?

Yes. Sending HTTP HEAD or GET requests to publicly accessible URLs is a standard part of how the internet works. Every web browser, search engine crawler, and uptime monitoring service does the same thing. HTTP Status Checker sends a single HEAD request per URL, which is the lightest possible request type and places minimal load on the target server.

The actor does not scrape page content, bypass authentication, or access restricted areas. It only reads the HTTP response headers that the server voluntarily provides. This is equivalent to what any visitor's browser receives when navigating to a URL.

If you are checking URLs on websites you do not own, be mindful of the volume and frequency of your requests. For very large lists, the concurrent request processing helps complete runs quickly without sustained load on any single server.

FAQ

Does the actor follow redirects? No. The actor reports the first status code returned by the server. If a URL returns a 301 or 302, the actor reports that redirect status and captures the redirect target in the redirectUrl field. Use the Redirect Chain Analyzer if you need to follow the full redirect chain.

Why does a URL show a different status code than my browser? The actor uses HEAD requests, which some servers handle differently than GET requests. Additionally, some servers return different responses based on the User-Agent header, geographic location, or rate limiting. The actor reports what it receives as an external client without cookies or session state.

Can I check URLs that require authentication? The actor sends standard HTTP requests without authentication headers. URLs behind login walls or requiring API keys will return 401 or 403 status codes. Custom authentication headers are not supported in this version.

What is the difference between 4xx and 5xx errors? A 4xx status code (client error) means the request was invalid -- the URL does not exist (404), you are not authorized (401/403), or the request was malformed. A 5xx status code (server error) means the server failed to process a valid request, indicating a problem on the server side such as an overloaded server or misconfigured backend.

A URL shows status code null or an error message. What does that mean? A null status code with an error message means the request could not reach the server at all. Common causes include DNS resolution failures (domain does not exist), connection timeouts (server is down or unreachable), SSL/TLS certificate errors, or malformed URLs. Check that the URL is correct and the site is accessible from a browser.

Can I check thousands of URLs in one run? Yes. The actor is designed for bulk checking and processes URLs concurrently. There is no hard limit on the number of URLs per run. At $0.0005 per URL, checking 10,000 URLs costs approximately $5.04 including the start fee.

How can I monitor URLs on a schedule? Use Apify Schedules to run the actor automatically at any interval (every 5 minutes, hourly, daily, weekly). Combine with a webhook or Slack integration to get notified when URLs change status or go down.

Why do some URLs show very high response times? High response times can indicate server performance issues, geographic distance between the checking server and the target, or servers that throttle HEAD requests. Response times above 5,000ms may indicate the server is under heavy load or has connectivity problems.

Can I use this to check internal or localhost URLs? No. The actor runs on Apify's cloud infrastructure and can only reach publicly accessible URLs. Internal network addresses (192.168.x.x, 10.x.x.x, localhost, etc.) are not reachable from the cloud environment.

What happens if I submit a URL without http:// or https://? The URL will fail with an error because the actor needs the full protocol to determine how to connect to the server. Always include http:// or https:// at the beginning of each URL.

How do you check HTTP status codes for a large list of URLs at once?

The most efficient way to bulk-check HTTP status codes is to use an automated checker rather than visiting each URL manually. HTTP Status Checker processes your entire list concurrently — meaning it sends requests to many URLs simultaneously rather than waiting for each one to finish before moving to the next. This makes it possible to check thousands of URLs in minutes instead of hours.

To do it:

1. Collect all your URLs into a plain list (one per line, or as a JSON array)
2. Paste them into the URL input field in HTTP Status Checker
3. Start the run and get a structured report showing the status code, response time, and redirect target for every URL

For recurring audits (weekly SEO checks, uptime monitoring), use Apify Schedules to automate the process. The results can be pushed directly to Google Sheets so you always have an up-to-date status report without manual work.

A single run can handle tens of thousands of URLs. At $0.0005 per URL, checking 10,000 URLs costs approximately $5 — far cheaper than paying for a dedicated uptime monitoring SaaS subscription.

What is the difference between a 301 and 302 redirect?

Both 301 and 302 are HTTP redirect status codes, but they carry different semantic meaning and have significant SEO implications:

• 301 Moved Permanently — The resource has moved to a new URL permanently. Search engines transfer the link equity ("PageRank") from the old URL to the new one and update their index. Use 301 for domain migrations, URL restructures, and permanent canonicalization.
• 302 Found (Temporary Redirect) — The resource is temporarily at a different URL. Search engines keep the original URL in their index and do not transfer link equity. Use 302 only when the redirect is genuinely temporary (e.g., A/B testing, maintenance pages).

Common mistakes that hurt SEO:

• Using 302 instead of 301 for permanent URL changes — you lose link equity
• Redirect chains (A → B → C) — each hop dilutes equity and slows page load
• Redirect loops (A → B → A) — crawlers give up and the page becomes inaccessible

HTTP Status Checker reports the redirect target URL from the Location header for every 3xx response. Use it to audit your redirects and catch chains or loops before they affect your rankings. Pair it with the Redirect Chain Analyzer to trace multi-hop redirect paths.

How do you find broken links on a website?

Broken links — URLs that return 404 Not Found or other error status codes — hurt both user experience and SEO. Search engines penalize sites with many broken internal links, and visitors who hit dead ends leave quickly.

There are two approaches depending on your goal:

Checking a specific list of URLs — If you already have a list of URLs to check (from a sitemap, a crawl export, or a spreadsheet of links), paste them directly into HTTP Status Checker. You'll get back every URL's status code, and you can filter for isClientError: true or isServerError: true to isolate the broken ones.

Crawling an entire website for broken links — If you want to discover broken links by following all internal links on a site, use the Broken Link Checker, which crawls the site and reports every broken link it finds along with the page that contains it.

Once you have a list of broken URLs, common fixes include:

• Setting up 301 redirects from dead URLs to the correct current URL
• Updating internal links to point directly to the new URL
• Removing links to external pages that no longer exist

How do you monitor website uptime automatically?

Website uptime monitoring means automatically checking whether your URLs are accessible and alerting you when they go down or return errors. HTTP Status Checker can serve as a lightweight uptime monitor for any number of URLs without requiring a dedicated monitoring tool.

The setup takes about two minutes:

1. Create an input file with all the URLs you want to monitor (homepage, key landing pages, API endpoints, checkout flow)
2. Go to Apify Schedules and set up a recurring run of HTTP Status Checker — hourly for critical pages, daily for less critical ones
3. Add a webhook to notify you when a run completes: connect to Slack via the Apify Slack integration, or use a custom webhook to post to any endpoint
4. In your notification handler, filter for results where isOk is false to trigger alerts only on actual failures

For a low-traffic website monitored hourly, the monthly cost is: 24 runs/day × 30 days × $0.035 start fee + URL count × $0.0005 = a few dollars per month. Most dedicated uptime monitoring SaaS tools charge $20–$100/month for similar coverage.

If you need sub-minute monitoring or SLA guarantees, a purpose-built uptime service is more appropriate. But for most websites, scheduled HTTP status checks provide sufficient coverage at a fraction of the cost.

What do different HTTP status code ranges mean?

HTTP status codes are grouped into five classes, each covering a different category of response:

Range	Class	Meaning
1xx	Informational	The server received the request and is continuing to process it
2xx	Success	The request succeeded. 200 OK is the standard success code
3xx	Redirection	The resource has moved; the client should follow the Location header
4xx	Client Error	The request was invalid or unauthorized — the problem is on the client side
5xx	Server Error	The server failed to process a valid request — the problem is on the server side

The most important individual codes to know:

• 200 OK — Standard success. Page loaded correctly.
• 301 Moved Permanently — URL has permanently moved. SEO juice transfers to the new URL.
• 302 Found — Temporary redirect. No SEO transfer.
• 304 Not Modified — Browser cache is still valid. No content sent.
• 401 Unauthorized — Authentication required.
• 403 Forbidden — Server refuses to serve the resource, even with valid credentials.
• 404 Not Found — URL does not exist. Most common broken link code.
• 410 Gone — URL existed but was permanently deleted. Stronger signal than 404 for search engines.
• 429 Too Many Requests — Rate limit hit. Slow down requests.
• 500 Internal Server Error — Generic server failure.
• 502 Bad Gateway — Upstream server returned an invalid response.
• 503 Service Unavailable — Server is temporarily overloaded or in maintenance.

HTTP Status Checker returns the isOk, isRedirect, isClientError, and isServerError boolean flags so you can filter results by category without writing code to check ranges.

Related scrapers

• Website Health Report — Comprehensive website health and SEO audit with SSL, DNS, headers, and performance checks
• Tech Stack Detector — Detect frameworks, CMS, analytics, and other technologies used by any website