Website Availability Checker — Pingdom Alternative

Check public website and API endpoints on demand. Return HTTP status, response time, redirects, TLS details, and expected-text checks per URL for deployment reviews and operational triage. For deployment operators, each dataset row is one current endpoint observation rather than a continuous monitoring history.

Workflow: put the results to work

List the public endpoints that must respond after a deployment. Specify acceptable HTTP statuses and a stable health phrase where useful, then inspect each endpoint observation. Use a monitoring system for continuous probes, alert delivery, or private-network checks.

When to use it

Use this Actor when you need a bounded programmatic release check for public websites, health endpoints, landing pages, or read-only API endpoints. Start with a small list of canonical public URLs, define the HTTP statuses that mean healthy, and optionally require a stable response phrase.

For private-network services, authenticated endpoints, browser journeys, customer telemetry, recurring alerts, or continuous uptime history, select a workflow designed for that scope. This Actor accepts public standard-port HTTP(S) endpoints and rejects local, credentialed, private, and non-standard-port URLs before a network request is made.

Deployment-check workflow

A release operator starts with the small set of public endpoints that must be healthy after a deployment, then supplies the expected HTTP status and a stable health phrase when it matters. The Actor returns one current record per endpoint, the operator reads the Dataset plus OUTPUT to identify any unavailable or indeterminate observations, and the team can then continue with the appropriate release or incident workflow.

What it returns

One Dataset row represents one endpoint availability report.

Field	Meaning
availabilityState	available, unavailable, or indeterminate based on the bounded check.
statusCode, responseTimeMs	Final HTTP response and elapsed time across accepted redirects.
tls	Certificate validity, issuer, subject, expiry, and a safe TLS diagnostic when available.
contentExpectation	Whether the optional expected text was checked and matched; the text itself is redacted from output.
diagnostic	Actionable status, content, DNS, timeout, connection, TLS, or safe-target explanation.
targetUrl, finalUrl, redirects, checkedAt	Source, final destination, accepted redirect path, and observation time.

The default key-value store also writes OUTPUT and RUN_SUMMARY on every terminal path. They expose the named outcome, persisted and incomplete counts, named-event charges, accepted targets, and warnings without including request credentials or response bodies.

Quick start

{
    "targets": [{ "url": "https://example.com" }, { "url": "https://example.com/health" }],
    "expectedStatusCodes": [200],
    "expectedText": "healthy",
    "checkTls": true,
    "timeoutSecs": 20,
    "maxRedirects": 3
}

The expected text is checked only in the first 512 KB of the final response and is redacted from actor output. Leave it blank for an HTTP-only availability check.

Example result

{
    "reportId": "availability-7d2c53f6a91a",
    "reportType": "deployment-availability-check",
    "targetUrl": "https://example.com/health",
    "finalUrl": "https://example.com/health",
    "availabilityState": "available",
    "isAvailable": true,
    "statusCode": 200,
    "responseTimeMs": 184,
    "redirects": [],
    "tls": {
        "checked": true,
        "valid": true,
        "issuer": "Example Certificate Authority",
        "subject": "example.com",
        "validTo": "ISO-8601 certificate expiration timestamp",
        "daysUntilExpiry": 116,
        "error": null
    },
    "contentExpectation": {
        "checked": true,
        "matched": true,
        "bodyTruncated": false
    },
    "diagnostic": null,
    "checkedAt": "ISO-8601 timestamp at completion"
}

Outcomes and operational states

Outcome	What it means
COMPLETE	Every accepted endpoint produced a validated, persisted availability report. An unavailable endpoint is still a useful completed observation.
PARTIAL	At least one report was persisted, while a target was rejected, a storage write was incomplete, or a caller cost cap stopped further checks.
INVALID_INPUT	The supplied endpoints, status codes, or expected text can be corrected before retrying; Dataset rows remain source-derived.
UPSTREAM_FAILED	Valid public targets were accepted, while an availability report was not persisted.
CONFIG_ERROR	The deployed Actor requires a configuration review before its advertised workflow can begin.

API usage

curl -X POST "https://api.apify.com/v2/acts/khadinakbar~pingdom-alternative/runs" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "targets": [{"url": "https://example.com/health"}],
    "expectedStatusCodes": [200],
    "expectedText": "healthy"
  }'

After completion, read the default Dataset for endpoint reports and the OUTPUT and RUN_SUMMARY keys for the terminal contract.

AI agent and MCP prompt card

Use this focused Actor through the available Apify MCP or Actor API path to check these authorized public deployment URLs for expected HTTP status, TLS validity, redirects, and an optional stable health phrase. Read back the Dataset and OUTPUT, preserve each source URL and collection time, state the named outcome and cost boundary, and treat indeterminate as a safe-probe boundary rather than proof that the service is down.

How this workflow compares with Pingdom

Decision	This Actor	Pingdom	Best fit
Bounded job	On-demand public endpoint availability records.	Broader website monitoring service.	Use this Actor for a small programmatic deployment check.
Input	One to five public URLs with explicit HTTP, TLS, content, timeout, and redirect expectations.	Broader monitoring configuration.	Use this Actor when the release contract is already known and small.
Billing	Per persisted report plus Apify platform usage.	Subscription configuration on its pricing page.	Compare exact cost only for a dated, equal workload.
Output	Structured Dataset and terminal records.	Monitoring product interface and its broader feature set.	Use this Actor when a JSON-like per-endpoint record is needed downstream.
Freshness	checkedAt and source URL on each current record.	Ongoing and historical monitoring capabilities.	Use this Actor for a point-in-time check.
Programmatic interface	Actor API call with Dataset and terminal-record readback; named client integrations remain outside the current claim.	Broader product workflow.	Choose based on the required operating surface.
Effective efficiency	A same-job timing and usable-output comparison is pending final private-build evidence.	No equal-workload timing has been captured.	Select either product only after an equal-workload throughput claim is measured.
Continuous monitoring	Out of scope.	Designed for ongoing monitoring.	Choose Pingdom when recurring probes and alerting are required.
RUM and transactions	Out of scope.	Product scope includes those capabilities.	Choose Pingdom for user telemetry or browser-flow monitoring.
Pricing and reliability	Exact same-job comparison is pending final private-build evidence.	Current plan comparison is pending a documented same-job benchmark.	Select either product only after a cost or reliability claim is measured.

Pingdom is a trademark of its owner. This independent Actor is not affiliated, associated, or endorsed by Pingdom.

Best results

• Supply only endpoints you are authorized to assess and expect to be publicly reachable.
• Use a stable health phrase, not a changing timestamp, for expectedText.
• Prefer a dedicated public health route for API checks.
• Keep the run small and schedule a saved task only after validating one representative report.
• Treat DNS, TLS, redirect, and safe-target diagnostics as the start of operational investigation, not as an automated remediation instruction.

Builder's note

I designed this Actor to make one release or incident check reproducible through a bounded input, a small per-endpoint record, and honest terminal outcomes. My goal was to keep public endpoint provenance, TLS observations, and safe diagnostics visible while concentrating the workflow on an on-demand deployment decision.

Responsible use

Check only public endpoints you are authorized to assess. Follow applicable laws, service terms, and your organization's security and operations policies. The actor records endpoint availability metadata, not page content, credentials, cookies, request bodies, or customer telemetry.

Pricing and run costs

This Actor uses Pay per event plus Apify platform usage. The Pricing tab lists the current event rates and billing terms.

Event	Billing unit	When it applies
apify-actor-start	Actor Start	Charged when the Actor starts running. Number of events charged depends on Actor memory (one event per GB, minimum one event).
availability-check	Availability check	Charged once for each validated endpoint availability report persisted to the Dataset.

Run cost combines the charged events and Apify platform usage. Review the run charge limit and requested result count before starting.

Connect an AI agent

Use the Apify MCP configurator to choose an available client connection. Inspect this Actor’s current input schema and required credentials before running it.