# SiteVerdict — SSL & Uptime Monitor with Status Page (`siteverdict/siteverdict-ssl-uptime-status-page`) Actor

Schedule it to check uptime, response time, keywords and SSL/TLS certificate expiry for your URLs, keep history, and publish a hosted static status page (HTML + JSON + uptime badges) with incidents. Alerts on down, recovery and expiring certificates via Slack or webhook.

- **URL**: https://apify.com/siteverdict/siteverdict-ssl-uptime-status-page.md
- **Developed by:** [Aman Thakran](https://apify.com/siteverdict) (community)
- **Categories:** Developer tools, Business
- **Security:** Limited permissions
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

Pay per event

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## 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

```json
{
  "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)

```json
{ "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.

# Changelog

This Actor's version history is a separate document: https://apify.com/siteverdict/siteverdict-ssl-uptime-status-page/changelog.md

# Actor input Schema

## `urls` (type: `array`):

One per line. Optionally name it: <code>Website | https://example.com</code>. https:// is added when missing. Max 200.

## `monitors` (type: `array`):

Optional per-URL settings: <code>\[{"url":"https://api.example.com/health","name":"API","expectKeyword":"ok","keywordMode":"present","acceptStatuses":\[200,204],"showUrl":false}]</code>

## `pageTitle` (type: `string`):

Shown at the top of the published status page.

## `publishPage` (type: `boolean`):

Writes status.html, status.json and one SVG uptime badge per monitor to the state store (public links are in OUTPUT and the dataset).

## `showUrlsOnPage` (type: `boolean`):

Turn off to show only the monitor names (e.g. for internal health endpoints).

## `timeoutSecs` (type: `integer`):

Per request.

## `slowResponseMs` (type: `integer`):

Responses slower than this are marked degraded.

## `tlsWarnDays` (type: `integer`):

Certificates expiring within this many days mark the check degraded and trigger an alert.

## `confirmFailures` (type: `boolean`):

Re-checks after 5 s before declaring a URL down (reduces false alarms from brief blips).

## `maxConcurrency` (type: `integer`):

How many URLs are checked in parallel (one request per origin per second).

## `historySize` (type: `integer`):

History used for uptime % and the status bars (1,000 checks = ~3.5 days at 5-minute intervals, ~10 days at 15 minutes).

## `stateStoreName` (type: `string`):

Named key-value store that keeps history and hosts the status page. Use one name per status page.

## `alertOn` (type: `array`):

Alerts are sent once per state change (not on every failing check).

## `webhookUrl` (type: `string`):

We POST a JSON digest of the run's alerts here. Stored encrypted, never logged.

## `slackWebhookUrl` (type: `string`):

https://hooks.slack.com/services/... Stored encrypted, never logged.

## `sampleMode` (type: `boolean`):

Simulated checks for three fictional example.com monitors with seeded history, so you can see the page, alerts and output. Nothing is charged.

## Actor input object example

```json
{
  "urls": [
    "Website | https://www.example.com/"
  ],
  "pageTitle": "Service status",
  "publishPage": true,
  "showUrlsOnPage": true,
  "timeoutSecs": 20,
  "slowResponseMs": 3000,
  "tlsWarnDays": 14,
  "confirmFailures": true,
  "maxConcurrency": 5,
  "historySize": 1000,
  "stateStoreName": "siteverdict-status-page",
  "alertOn": [
    "down",
    "recovery",
    "tls-expiring",
    "tls-untrusted"
  ],
  "sampleMode": false
}
```

# Actor output Schema

## `results` (type: `string`):

No description

## `output` (type: `string`):

No description

## `files` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "urls": [
        "Website | https://www.example.com/"
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("siteverdict/siteverdict-ssl-uptime-status-page").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "urls": ["Website | https://www.example.com/"] }

# Run the Actor and wait for it to finish
run = client.actor("siteverdict/siteverdict-ssl-uptime-status-page").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "urls": [
    "Website | https://www.example.com/"
  ]
}' |
apify call siteverdict/siteverdict-ssl-uptime-status-page --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,siteverdict/siteverdict-ssl-uptime-status-page"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/N0YSF5YbdWvKsrStC/builds/4jipedbcMNRpzVJ5D/openapi.json