SiteVerdict — SSL & Uptime Monitor with Status Page

Schedule it, and you get uptime + SSL certificate monitoring for your URLs, alerts when something breaks, and a hosted public status page with history, incidents and uptime badges. No servers, no agents, no subscription.

What you get on every run

• ✅ Uptime check per URL: HTTP status, response time, time to first byte, redirects followed, optional keyword (must contain / must not contain), custom accepted status codes.
• 🔒 SSL/TLS certificate: days to expiry (full days left; negative = expired), valid-to date, issuer, subject, protocol, trusted or not, and a tlsStatus of valid, expiring, expired, self-signed, hostname-mismatch, untrusted or not-checked (the certificate could not be read on this run — never shown as OK).
• 🕒 History & uptime % (24 h, 7 d, 30 d) kept in a named key-value store between runs.
• 📟 Static status page (status.html): overall banner, one card per monitor with colour bars for recent checks, uptime figures, average response time, certificate days left and recent incidents. Self-contained HTML (no JavaScript, no trackers), dark-mode aware, mobile friendly.
• 🧾 status.json for your own dashboards and SVG uptime badges (badge-<id>.svg) for READMEs.
• 🚨 Alerts (Slack or any webhook) once per state change: went down, recovered (with outage length), certificate expiring (at your warn days, then 7, 3, 1 and expired), certificate not trusted, optional slow (sent on every slow check, $0.01 each).
• 🛡️ Fewer false alarms: a failure is re-checked once after 5 s before it counts as down; bot-protection pages are reported as blocked, not down.
• 🔎 Why it is down, machine-readable: every down row has a failure such as timeout, connection-refused, dns-failure, connection-reset, http-status, keyword-missing, tls-expired, tls-self-signed, tls-hostname-mismatch or tls-untrusted, plus the raw errorCode.

Who it is for

• Small SaaS teams, agencies and freelancers who want a public status page and SSL expiry alerts for client sites without another monthly tool.
• Ops engineers who need a second-opinion check from outside their own infrastructure.
• Agencies reporting uptime to clients (badges + JSON).
• AI agents via the MCP tool ssl_uptime_status (one-off checks of a list of URLs).

Quick start

1. Add URLs: Website | https://www.example.com, API | https://api.example.com/health.
2. Set a page title, alert channels (optional) and run once. Open the statusPageUrl from the dataset or OUTPUT.
3. Create an Apify Schedule (e.g. every 5 or 15 minutes) with the same input. Every run appends history and republishes the page at the same URL.

Try Sample mode first: three fictional example.com monitors with seeded history, an outage and an expiring certificate. No network, no charge.

Example input

{
  "urls": ["Website | https://www.example.com", "Shop | https://shop.example.com"],
  "monitors": [{ "url": "https://api.example.com/health", "name": "API", "expectKeyword": "ok", "showUrl": false }],
  "pageTitle": "Example Ltd — service status",
  "tlsWarnDays": 21,
  "slackWebhookUrl": "https://hooks.slack.com/services/…",
  "stateStoreName": "example-status"
}

Example output (check row)

{ "recordType": "check", "name": "API", "url": "https://api.example.com/health", "status": "down", "failure": "http-status", "reasons": ["HTTP 503"],
  "httpStatus": 503, "responseTimeMs": 140, "confirmedByRetry": true, "tlsStatus": "valid",
  "tls": { "daysToExpiry": 64, "issuer": "Let's Encrypt", "trusted": true, "protocol": "TLSv1.3" },
  "uptime24h": 95.83, "uptime7d": 99.1, "uptime30d": 99.6 }

Status page hosting

The page, JSON and badges live in your named key-value store (stateStoreName). The record URLs shown in the output are stable across runs. If your store is private, Apify gives signed public links; you can also embed status.json in your own site or point a CNAME/iframe at the page.

Pricing (pay per event)

Event	Price	When
url-check	$0.0003	a URL was checked and got an up / degraded / down verdict
status-page-published	$0.0002	the status page, JSON and badges were republished (once per run)
incident-alert	$0.01	an alert row (down, recovery, certificate, slow) was produced

Examples: 5 URLs every 15 minutes for 30 days ≈ 14,400 checks + 2,880 page updates ≈ $4.90/month, plus $0.01 per incident. 20 URLs checked once a day for SSL expiry ≈ $0.19/month. Blocked, robots-disallowed and invalid URLs are never charged.

Max cost per run is respected. If the run reaches its maximum total charge, URLs that could not be checked get a free skipped row ("Not processed (max total charge reached)"), the run status says e.g. "2 not processed (max total charge reached)", and nothing further is charged. The status page is only republished, and alerts are only sent to Slack/webhook, when their event was charged. A run whose budget exactly covers its work is not reported as stopped.

FAQ

How often can it check? As often as your Apify schedule runs (every minute is possible; 5-15 minutes is typical).

Does it respect robots.txt? Yes. If a site's robots.txt disallows our SiteVerdict user agent for the path, the check is skipped and reported. For your own site add User-agent: SiteVerdict / Allow: /. TLS certificate checks are a handshake only.

Can it monitor private/internal hosts? No. Private, loopback, link-local and cloud-metadata addresses are blocked, including after redirects and at connection time, so a DNS answer that changes between the check and the connection cannot reach an internal address (SSRF protection). This applies to the HTTP check, the TLS handshake, robots.txt and alert webhooks.

Will it get past Cloudflare challenges? No, by design. Such checks are marked blocked and excluded from uptime.

Limits

• 200 monitors per run; history up to 5,000 checks per monitor (default 1,000).
• Single location (Apify cloud); this is not a multi-region probe network.
• HTTP(S) only on ports 80, 443, 8080, 8443; no ICMP/TCP/DNS-only checks.

Sources & compliance

• Data comes only from the URLs you list (HTTP requests + TLS handshake) with the honest user agent SiteVerdict/ssl-uptime-status-page (+hello@webrevenuescan.com) and at most one request per origin per second. robots.txt is read once per origin per run (RFC 9309).
• No personal data is collected. Webhook/Slack URLs are secret inputs, never logged or written to the dataset.
• Only monitor sites you own or are authorised to check. Not affiliated with any status-page vendor.