Website Uptime Checker — Is It Down? Status, SSL Monitor
Pricing
from $8.00 / 1,000 uptime checks
Website Uptime Checker — Is It Down? Status, SSL Monitor
Check whether a website is up or down — a health check and uptime monitor without a subscription. Input: urls array. Output: JSON per URL with up/down, HTTP status, latency in ms, SSL validity. Schedule as a cron to monitor continuously. $0.01 per URL checked.
Pricing
from $8.00 / 1,000 uptime checks
Rating
0.0
(0)
Developer
Broke to Built
Maintained by CommunityActor stats
0
Bookmarked
1
Total users
0
Monthly active users
9 days ago
Last modified
Categories
Share
Website Uptime Checker — is a website up? HTTP status, latency & SSL, in bulk
Check whether a website is up without installing a monitor or signing up for a monitoring plan. Give this Actor a URL — or 200 of them — and get back a plain up/down verdict per site, the HTTP status code, response time in milliseconds, the final URL after redirects, the response size, and whether the SSL certificate validates. It runs on demand and is built to be called from code and by AI agents, not just clicked.
$0.01 per URL checked. No subscription, no per-monitor fee, no minimum. You pay for the checks you actually run.
What problem this solves
Most uptime tools want you to create an account, add each site as a "monitor", and pay monthly for slots you may only need once. But a lot of real uptime questions are one-off: did that deploy actually come back up? which of these 80 client domains are dead? is that certificate still valid?
This is that check as a hosted call. Nothing to install, nothing to keep running, no monitor slots to manage — one run, one answer per URL, results in your own dataset.
Who uses it
- Developers checking a deploy — one call, one verdict, before and after a ship.
- Agencies and freelancers auditing a domain list — paste every client site, get a table of what is down, how slow it is, and whose SSL has stopped validating.
- AI agents that need a factual "is this site reachable right now" before they quote it, crawl it, or tell a user it is broken.
- No-code / automation builders (Make, n8n, Zapier-style flows) that can call a URL but cannot open a raw socket to test TLS.
- Anyone with a spreadsheet of URLs who needs to know which ones still resolve.
Quick start
{"url": "https://github.com"}
That is the whole minimum input. Everything else is optional.
Bulk is just as short:
{"urls": ["https://google.com", "example.com", "https://yoursite.dev"]}
All input options
| Field | Type | Required | What it does |
|---|---|---|---|
url | string | one of url/urls | A single URL or bare domain. Scheme optional — https:// is assumed |
urls | string[] | one of url/urls | More URLs to check in the same run |
expectStatus | number | no | Status code you consider "up" (default 200). Any 2xx/3xx also counts as up |
maxUrls | number | no | Cap on URLs checked this run (default 50, hard max 200) |
url and urls are merged, duplicates are removed, and the list is trimmed to
maxUrls. A run with no usable URL fails immediately rather than charging you.
What you get back
One dataset item per URL:
{"url": "https://github.com/","finalUrl": "https://github.com/","up": true,"status": 200,"expectStatus": 200,"latencyMs": 253,"contentLength": 564076,"tlsValid": true,"checkedAt": "2026-06-25T02:20:01.440Z"}
up—truewhen the request completed and the status matchedexpectStatusor fell in the 2xx/3xx range.status— the HTTP status of the final response, ornullif the request never completed.latencyMs— wall-clock milliseconds from request start to the full body being read.contentLength— thecontent-lengthheader when the server sends one, otherwise the actual number of bytes received.finalUrl— where the request landed after following redirects.tlsValid— forhttps://targets, whether the certificate chain validated on a direct TLS connection.nullfor plainhttp://.checkedAt— ISO timestamp of the check.
A URL that cannot be reached still returns an item, with up: false and a short
error string:
{"url": "https://httpstat.us/404","up": false,"status": null,"latencyMs": 482,"tlsValid": false,"checkedAt": "2026-06-25T02:20:03.436Z","error": "fetch failed"}
One dead host never kills the rest of the batch.
Use it as an AI agent tool
This Actor is callable over Apify MCP, so an agent can verify a site is live mid-conversation instead of guessing. The shape an agent needs:
- Tool: this Actor
- Input:
{ "url": "<site url>" }or{ "urls": ["...", "..."] } - Returns:
up,status,latencyMs,tlsValidper URL
Useful as a fact-check step before an agent reports a link as broken, or as a pre-flight before it spends a longer scraping run on a host that is already down.
Pricing, plainly
$0.01 per URL checked (pay-per-event: url-checked). Checking 50 URLs costs
$0.50; the 200-URL maximum costs $2.00. No monthly fee and no per-monitor charge.
A URL is charged when it is checked, whether the answer is up or down — a "down" verdict is the product, so it costs the same as an "up" one.
Honest limits
Worth knowing before you run it, so nothing surprises you:
- It is a checker, not a monitor. Each run is a single point-in-time check. There is no built-in scheduling, alerting, email/webhook notification, or uptime percentage over time, and no memory of previous runs. If you want it recurring, put it on an Apify schedule and compare the datasets yourself.
- One attempt per URL, no retries. A momentary blip reads as down. The request times out after 20 seconds; the separate TLS probe times out after 10.
- Checks run one URL at a time, in order. 200 slow or timing-out hosts take a while — this is not a parallel sweep.
- No proxy support. Requests come from Apify's datacenter IPs with a fixed
EliBot/1.0user agent. Sites behind aggressive bot protection may answer with a challenge page or a 403, and that will read as down even though a browser gets through. - Single vantage point. No multi-region checking, so it cannot tell you a site is up in one country and down in another.
expectStatusnarrows nothing on its own. Any 2xx/3xx is treated as up in addition to your expected code, so settingexpectStatus: 404will not make a healthy 200 count as down.- It is a GET, and the whole body is read to measure size. Very large pages cost more time and bandwidth than a HEAD-style ping would.
tlsValidis a pass/fail flag, not a certificate report. No expiry date, no issuer, no chain details, and it is computed independently ofup.- No content assertions. It does not check for a keyword in the page, a JSON field, or a specific response header — only reachability, status, timing, size and TLS validity.
- Hard cap of 200 URLs per run. Ask for more and the list is trimmed.
FAQ
How do I check if a website is up right now?
Run this Actor with { "url": "https://example.com" }. It returns up: true/false
plus the HTTP status, response time and SSL validity for that moment.
Can I check hundreds of URLs at once?
Yes — pass them in urls. The default cap is 50 per run and the hard maximum is 200.
Each URL becomes its own dataset item and its own $0.01 charge.
Does it check the SSL certificate too?
For https:// targets it opens a direct TLS connection and reports tlsValid —
true when the certificate chain validates, false when it does not. It does not
report the expiry date or issuer. Plain http:// URLs get tlsValid: null.
What happens if a site is down or the domain does not resolve?
You still get an item for it, with up: false, status: null and a short error
message. The run keeps going and the other URLs are still checked.
Can I use it as an uptime monitor with alerts?
Not on its own — there is no alerting or notification built in. It performs the check; you decide what to do with the result. Running it on an Apify schedule and reacting to the dataset is the usual pattern.
Do I have to include https:// in the URL?
No. A bare domain like example.com is accepted and https:// is assumed. The
normalized URL comes back in the url field so you can see what was actually checked.
Why is my site reported as down when it loads fine in my browser?
Most often bot protection. Checks come from a datacenter IP with a fixed user agent and no proxy, so a challenge page or a 403 can look like downtime. A 20-second timeout on a very slow host does the same.
How do I treat a specific status code as healthy?
Set expectStatus. Note that 2xx and 3xx responses are always counted as up as well,
so expectStatus widens what counts as healthy rather than restricting it.
Can an AI agent call this?
Yes — it is exposed through Apify MCP as an agent tool. See "Use it as an AI agent tool" above.
Who made this
Broke to Built — a company of machines, building things it gives away. This is one of them; the rest are free too.
For AI agents
This Actor is built to be called by software, not just by people.
- Mount it directly as an MCP tool — no Store search, no ranking, just this one tool:
https://mcp.apify.com/?actors=eliai/website-uptime-checker - Or call it over HTTP and get the results in the same request:
POST https://api.apify.com/v2/acts/eliai~website-uptime-checker/run-sync-get-dataset-items - Pay with x402, without an Apify account. This Actor is whitelisted for agentic payments, so an agent holding USDC on Base can buy a prepaid token and spend it here. The minimum purchase is $1, the token balance is an absolute spending cap, and it expires 14 days after purchase.
- Costs are predictable before you call. Pricing is pay-per-event (see Pricing above), so an agent can budget a run in advance instead of discovering the bill afterwards.
- Send only the field you mean. If you pass the bulk field, it is used on its own; the single-value field is a fallback, never merged into your request. You are charged for the items you sent and nothing else.