HTTP Status Checker

HTTP Status Checker verifies whether URLs are live with lightweight HTTP HEAD requests, automatically retrying with GET when a server rejects HEAD with 405 or 501. It returns the status code, actual request method, response time, redirect target, and server header for each URL. Check up to 200 URLs per run for broken links and server errors, or opt in to bounded redirect-chain tracing.

What does HTTP Status Checker do?

HTTP Status Checker takes a list of URLs and first sends an HTTP HEAD request to each one. If the server reports that HEAD is unsupported with 405 or 501, the Actor retries that URL with GET and stops reading as soon as response headers arrive. For every URL, it reports the HTTP status code (200, 301, 404, 500, etc.), actual request method, fallback reason, 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 up to 200 URLs concurrently in batches and returns a structured JSON, CSV, or Excel report. Failed requests (DNS errors, timeouts, unreachable hosts) are captured with an error message instead of silently dropped, so every accepted URL produces a result.

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
• HEAD-to-GET compatibility fallback -- prevents false failures when a server rejects HEAD with 405 or 501, while requestMethod, usedGetFallback, and fallbackReason make the retry transparent
• Response time measurement -- measures the complete check in milliseconds, including a compatibility retry when needed
• Opt-in redirect-chain tracing -- set followRedirects to follow relative or absolute Location headers and return redirectChain, finalUrl, and finalStatusCode; maxRedirects bounds tracing from 1 through 10
• 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 up to 200 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
• Predictable cost -- one url-checked event is charged per original URL, never per redirect hop

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")
requestMethod	string or null	Method that produced the reported response: HEAD normally or GET after fallback
usedGetFallback	boolean	Whether the server rejected HEAD with 405/501 and GET was used
fallbackReason	string or null	HEAD_405 or HEAD_501 when fallback occurred
error	string or null	Error message if the request failed entirely
checkedAt	string	ISO 8601 timestamp of when the check was performed
finalUrl	string or null	Last observed URL when followRedirects is enabled; otherwise null
finalStatusCode	number or null	Status of the last observed hop when tracing is enabled; otherwise null
redirectCount	number	Number of redirects followed; 0 when tracing is disabled
redirectChain	array	Observed hops with URL, status, timing, and method/fallback metadata; empty when tracing is disabled
redirectTerminationReason	string or null	Why tracing stopped, such as non_redirect, max_redirects, or repeated_url; null when disabled

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
50 URLs	$0.035 + 50 x $0.0005	$0.060
100 URLs	$0.035 + 100 x $0.0005	$0.085
200 URLs (run maximum)	$0.035 + 200 x $0.0005	$0.135

There are no monthly fees or subscriptions. You only pay for what you use. Redirect hops do not create extra url-checked charges.

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	--	Up to 200 URLs to check. URLs without a protocol are normalized to https://.
followRedirects	boolean	No	false	Follow a bounded redirect chain while preserving the first response in the existing top-level fields.
maxRedirects	integer	No	5	Maximum redirects to follow when tracing is enabled. Accepted range: 1-10.

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"
    ],
    "followRedirects": true,
    "maxRedirects": 5
}

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",
    "requestMethod": "HEAD",
    "usedGetFallback": false,
    "fallbackReason": null,
    "error": null,
    "checkedAt": "2026-03-01T12:00:00.000Z",
    "finalUrl": null,
    "finalStatusCode": null,
    "redirectCount": 0,
    "redirectChain": [],
    "redirectTerminationReason": null
}

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",
    "requestMethod": "HEAD",
    "usedGetFallback": false,
    "fallbackReason": null,
    "error": null,
    "checkedAt": "2026-03-01T12:00:00.000Z",
    "finalUrl": null,
    "finalStatusCode": null,
    "redirectCount": 0,
    "redirectChain": [],
    "redirectTerminationReason": null
}

A 301 redirect with tracing enabled:

{
    "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",
    "requestMethod": "HEAD",
    "usedGetFallback": false,
    "fallbackReason": null,
    "error": null,
    "checkedAt": "2026-03-01T12:00:00.000Z",
    "finalUrl": "https://httpstat.us/",
    "finalStatusCode": 200,
    "redirectCount": 1,
    "redirectChain": [
        { "url": "https://httpstat.us/301", "statusCode": 301, "location": "https://httpstat.us", "responseTimeMs": 180, "requestMethod": "HEAD", "usedGetFallback": false, "fallbackReason": null },
        { "url": "https://httpstat.us/", "statusCode": 200, "location": null, "responseTimeMs": 165, "requestMethod": "HEAD", "usedGetFallback": false, "fallbackReason": null }
    ],
    "redirectTerminationReason": "non_redirect"
}

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.
• Trace redirects when needed -- enable followRedirects to capture each observed hop and final status in the same run; leave it disabled for the original first-response-only workflow.
• 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

For workflows beyond the 200-URL list checker, use the Redirect Chain Analyzer for specialized redirect analysis or the Broken Link Checker for crawling entire websites.

API usage

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.

Legality

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 normally sends one lightweight HEAD request. Only when the server explicitly rejects HEAD with 405 or 501 does it send a GET retry, and it stops reading that response after receiving the headers.

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? Only when you opt in. Set followRedirects: true to follow up to maxRedirects hops (default 5, maximum 10). The existing statusCode, statusText, category flags, and redirectUrl still describe the original URL's first response; redirectChain, finalUrl, and finalStatusCode describe the trace. Redirect loops, missing or invalid Location headers, timeouts, and the hop limit stop safely.

Why does a URL show a different status code than my browser? The Actor normally uses HEAD, but automatically retries with GET when HEAD returns 405 or 501. Check requestMethod, usedGetFallback, and fallbackReason to see which method produced the reported status. Other differences can still come from User-Agent handling, geography, cookies, session state, or rate limiting.

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.

How many URLs can I check in one run? Each run accepts up to 200 URLs after normalization and deduplication. Extra input entries are not processed. Split a larger inventory across multiple runs.

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 actor adds https:// before checking it. Include an explicit http:// URL only when you specifically need to test plain HTTP.

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

The most efficient way to check a known URL list is to use an automated checker rather than visiting each URL manually. HTTP Status Checker processes up to 200 URLs concurrently in batches, rather than waiting for each URL to finish before starting the next.

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 handles up to 200 URLs. Larger inventories can be split across runs while preserving one result and one url-checked charge per original URL.

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 first redirect target from the Location header for every 3xx response. Enable followRedirects to populate redirectChain and identify multi-hop paths, repeated URLs, and the final observed status before they affect rankings.

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