Website Uptime Monitor – Status, Response Time & SSL

Website uptime monitoring for client sites and deployments

Check public websites in bulk and get HTTP status, response time, redirect destination and SSL verification in a flat dataset. Add expected status codes and a response-time threshold to distinguish “responded” from “healthy for my workflow.” A separate coverage report flags URLs left unchecked by your limits, so an incomplete run cannot look like an all-clear.

Use it for agency client portfolios, campaign landing pages, public API health endpoints and deployment checks. Run once or save your input as an Apify task and schedule repeat checks. No target-site API key, proxy setup or browser installation is needed.

Copy the deployment health-check example to try the configured rules. It includes a deliberately missing page: the run can succeed while reporting an unhealthy URL. Replace the demo URLs before using it for your own checks.

How to check website uptime

1. Enter your public URLs or bare domains. Bare domains use HTTPS; duplicate normalized URLs are checked once.
2. Optionally set Expected HTTP status codes, Maximum healthy response time and your URL/spending limits. Leave health rules empty for the default HTTP 200–399 rule.
3. Start the run. Review the dataset and open Coverage and health summary under Output. Download JSON, CSV or Excel, or read both outputs through the API.

{
  "urls": ["https://example.com", "https://apify.com"],
  "expectedStatusCodes": [200],
  "maxResponseTimeMs": 5000,
  "timeoutSec": 15,
  "maxItems": 200
}

Rules apply to every URL. Use separate tasks for endpoints with different expectations. The Input tab explains each option.

What data does the uptime checker return?

Field	Meaning
url, checked_at	Normalized requested URL and UTC observation time
up	Final HTTP status is 200–399; unchanged by custom rules
healthy	No transport error and all configured health rules passed
health_issues	Reasons such as unexpected_status, slow_response, timeout or dns_error
status_code	Final HTTP status after redirects; null without a response
response_time_ms	DNS, connection and redirects through final headers, not page load time
http_status_expected	Whether final status matches your rule; null without a response
response_time_ok	Whether latency meets your threshold; null if not configured or unavailable
final_url, redirected	Final destination and whether a redirect was followed
ssl_valid	True after verified final HTTPS response, false for a certificate error, otherwise null
server, content_type, content_length	Response headers when available
error, error_type	Request failure description and stable category

For example, an HTTP 404 can be up: false and healthy: true if you explicitly expect [404]. A slow HTTP 200 can be up: true and healthy: false. Existing consumers of up retain their original behavior.

Coverage report: avoid a false all-clear

RUN_SUMMARY in the run's default key-value store provides:

• requested_unique_urls, selected_urls, checked_urls: supplied, selected by your cap and delivered observations.
• omitted_by_max_items, skipped_urls, unprocessed_urls: input truncated by your cap, blocked targets and selected URLs without a saved observation.
• healthy_count, unhealthy_count, unhealthy_urls: health results for delivered observations.
• previous_items, new_items: restored and newly delivered observations when the same run resumes.
• finished, run_error, complete, all_healthy: workflow gates.

For an all-clear, require run status SUCCEEDED, finished=true, complete=true and all_healthy=true. A run may succeed even when a website is down: that is a valid measurement. complete=false means not every supplied unique URL has a saved observation, including when maxItems truncates the input. Missing summaries from older builds, aborted runs or failed initialization are not an all-clear.

Output example

The following excerpt is from a live local check; latency varies by run:

{
  "url": "https://example.com/",
  "up": true,
  "healthy": true,
  "health_issues": [],
  "status_code": 200,
  "response_time_ms": 412,
  "http_status_expected": true,
  "response_time_ok": true,
  "ssl_valid": true,
  "checked_at": "2026-10-19T21:32:35.984843+00:00"
}

Pricing and recurring checks

Current base Actor charges are $0.50 per 1,000 delivered URL observations, plus $0.00005 per start at the configured 512 MB. An unreachable public website still produces a useful, billed observation. Blocked non-public targets are recorded separately without a dataset row.

Example	Actor charges
100 URLs, one run	$0.05005
1,000 URLs, one run	$0.50005
20 URLs hourly for 30 days: 14,400 checks, 720 starts	$7.236
100 URLs hourly for 30 days: 72,000 checks, 720 starts	$36.036

These are usage examples, not subscription prices. Review the live Pricing tab and your Apify plan for discounts and applicable charges. Set a maximum cost per run; when the result budget is exhausted, no new wave of checks starts. Already running checks may finish without producing a paid row. No external proxy or third-party API is used.

Scheduled monitoring and alerts

Save and test your input as a task, then add it to an Apify Schedule. Start hourly; choose a shorter interval only when the detection time and cost suit your sites. A new run makes new observations. Resurrecting the same run retains its existing observations instead of checking them again.

For Make, n8n, Zapier or your own service:

1. Receive an ACTOR.RUN.SUCCEEDED webhook from the task.
2. Read RUN_SUMMARY from that run's defaultKeyValueStoreId and the rows from defaultDatasetId using Apify credentials stored in your integration.
3. Route complete=false to an incomplete-check branch; route unhealthy_count > 0 to a website-health branch. Send notifications through the destination you configure.
4. Separately handle ACTOR.RUN.FAILED, ACTOR.RUN.TIMED_OUT and ACTOR.RUN.ABORTED, and monitor missing runs if your workflow requires it.

A run-success webhook is not an outage alert and does not itself filter unhealthy rows. The Actor sends no emails or messages and creates no schedules automatically. See the webhook event documentation.

Python API and deployment gate

Install apify-client==3.2.0 and set APIFY_TOKEN through your environment or CI secret store. This example starts one capped run and exits unsuccessfully if the result is unhealthy or incomplete:

import os
from datetime import timedelta
from decimal import Decimal
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("ninhothedev/website-uptime-monitor").call(
    run_input={"urls": ["https://example.com"],
               "expectedStatusCodes": [200], "maxResponseTimeMs": 5000},
    memory_mbytes=512, run_timeout=timedelta(seconds=120),
    max_total_charge_usd=Decimal("0.10"),
)
if run is None or run.status != "SUCCEEDED":
    raise SystemExit(2)
record = client.key_value_store(run.default_key_value_store_id).get_record("RUN_SUMMARY")
summary = record["value"] if record else {}
if (summary.get("finished") is not True or summary.get("complete") is not True
        or summary.get("run_error") is not False):
    raise SystemExit(2)
for row in client.dataset(run.default_dataset_id).iterate_items():
    print(row["url"], row["healthy"], row["health_issues"])
raise SystemExit(0 if summary.get("all_healthy") is True else 1)

Exit 0 means healthy, 1 means a health rule failed, and 2 means the run was incomplete or unsuccessful. Handle client/network exceptions as failed checks too. Keep credentials out of logs and URLs.

Limits and troubleshooting

Does “unhealthy” mean down for everyone? No. This is an observation from one Apify runtime location. HTTP 403/429 can mean blocking or rate limiting. It does not measure global uptime, availability between checks or a contractual SLA percentage.

Does it render pages or inspect page content? No. It sends a GET and stops after final headers. Redirects can require additional requests, with up to ten hops and a total deadline per URL. There are no automatic retries. It does not detect broken JavaScript, login flows or content errors behind a healthy HTTP response.

What does SSL verification cover? Certificate verification on HTTPS connections; no certificate expiry date is extracted. An HTTPS-to-HTTP redirect ends with ssl_valid: null.

Which targets are supported? Public HTTP(S) URLs only. Invalid input fails before checks start. Private, loopback and link-local addresses are not supported; redirects or DNS answers leading there are recorded in SKIPPED_TARGETS without a billed row. Check only endpoints you are permitted to monitor and choose a reasonable frequency.

Need help? Open an issue in the Actor's Issues tab with a run ID and a non-sensitive example URL. Do not include credentials.

Related tools

• Redirect Chain Tracer: inspect individual redirect hops.
• HTTP Security Headers Checker: inspect security header configuration.