Vendor Status Intelligence API

What does Vendor Status Intelligence API do?

Vendor Status Intelligence API turns public SaaS and cloud status pages into one consistent dataset. Add status-page URLs for vendors such as OpenAI, GitHub, or Slack, and the Actor returns current health, affected components, active incidents, recent incident history, and incident-window metrics.

The Actor runs on the Apify platform, so the same workflow can be called through an API, scheduled, monitored, connected to webhooks, or exported to common data formats. It supports Atlassian Statuspage-compatible JSON endpoints, Slack’s public Status API, RSS or Atom incident feeds, and a best-effort HTML fallback.

Why use Vendor Status Intelligence API?

Modern teams depend on many outside services, but every vendor publishes status differently. Opening ten tabs during an incident is slow, and copying incident timelines into vendor reviews or audit evidence is tedious.

Use this Actor to:

• Build a single health dashboard for a SaaS or cloud stack.
• Feed vendor incidents into Slack, email, Jira, Make, Zapier, or an internal workflow.
• Compare publicly reported incident frequency and duration during procurement or renewal reviews.
• Retain repeatable evidence for vendor-risk, business-continuity, SOC 2, or ISO 27001 processes.
• Give support and operations teams a fast way to determine whether a dependency is reporting an outage.

The output is deliberately evidence-based. incidentFreePercent measures time without a publicly reported incident interval in the selected window. It is not an independent uptime test, an SLA measurement, or a guarantee that the vendor reported every problem.

How to use Vendor Status Intelligence API

1. Open the Actor in Apify Console.
2. Add one or more public vendor status-page URLs.
3. Choose an incident-history window, such as 30 or 90 days.
4. Decide whether scheduled maintenance should count in the history.
5. Click Start.
6. Review the overview table or download the complete dataset.
7. For ongoing monitoring, create an Apify Schedule and attach the integration or webhook you prefer.

The Actor also supports Standby mode. Send the same JSON input to POST /audit on the Actor’s Standby hostname for a synchronous JSON response.

The Standby tab includes an interactive API specification, request example, and response schema.

Input

The Input tab contains all supported options. A typical request is:

{
    "statusPageUrls": [
        "https://status.openai.com",
        "https://www.githubstatus.com",
        "https://status.slack.com"
    ],
    "sinceDays": 90,
    "maxIncidentsPerVendor": 50,
    "includeMaintenances": false,
    "maxConcurrency": 5,
    "requestTimeoutSeconds": 20,
    "failOnError": false
}

Each run accepts up to 100 unique public status-page URLs. Private, local, and reserved network targets are rejected.

Supported status pages

The Actor has first-class support for Atlassian Statuspage-compatible public APIs and Slack Status, plus RSS/Atom incident feeds and a best-effort HTML fallback. A live compatibility check across 25 well-known vendors produced 19 full structured results, 6 caller-visible partial results, and no failed collections.

Full structured coverage included OpenAI, GitHub, Slack, Cloudflare, Discord, Atlassian, Twilio, Zoom, Datadog, Reddit, Dropbox, Vercel, Figma, Canva, Supabase, Netlify, Sentry, MongoDB, and Notion. See PROVIDER_COVERAGE.md for the dated matrix and interpretation.

Output

Every submitted URL produces one top-level dataset item, including failed requests:

{
    "requestUrl": "https://www.githubstatus.com/",
    "provider": "atlassian-statuspage",
    "vendorName": "GitHub",
    "collectionStatus": "success",
    "currentIndicator": "operational",
    "needsAttention": false,
    "activeIncidentsCount": 0,
    "incidentsInWindow": 8,
    "reportedIncidentMinutes": 214,
    "incidentFreePercent": 99.8349,
    "recentIncidents": [
        {
            "id": "incident-123",
            "title": "Degraded performance",
            "status": "resolved",
            "impact": "minor",
            "url": "https://www.githubstatus.com/incidents/example",
            "startedAt": "2026-07-20T10:00:00.000Z",
            "resolvedAt": "2026-07-20T10:45:00.000Z",
            "durationMinutes": 45,
            "affectedComponents": ["API Requests"],
            "latestUpdate": "This incident has been resolved.",
            "isMaintenance": false
        }
    ],
    "collectedAt": "2026-07-28T15:00:00.000Z"
}

You can download the dataset in various formats such as JSON, HTML, CSV, or Excel.

Data table

Field	Description
provider	Detected status-page implementation
currentIndicator	Normalized operational, degraded, outage, maintenance, or unknown state
needsAttention	Quick flag for non-operational states, active incidents, or partial/failed collection
components	Public service components and their reported states
activeIncidents	Currently unresolved public incidents
recentIncidents	Incidents overlapping the selected history window
reportedIncidentMinutes	Union of known public incident intervals, without double-counting overlaps
incidentFreePercent	Percentage of the window with no known public incident interval
sourceEndpoints	Public URLs used as evidence for the record
error	Explanation when collection is partial or failed

How much does it cost to monitor vendor status pages?

This Actor uses lightweight public HTTP requests and does not launch a browser, so compute usage should remain low for ordinary watchlists. Actual cost depends on the number of vendors, history depth exposed by each provider, run frequency, memory setting, and your Apify plan.

Start with a small watchlist and inspect the run’s platform-usage statistics before creating a frequent schedule. A daily run is usually enough for governance reporting; operational alerting may justify a shorter interval. Apify’s free platform credits, when included in your current plan, can be used for trial runs.

Advanced options

• Use a shorter sinceDays value for lightweight daily digests.
• Enable includeMaintenances when planned work matters to business-continuity reporting.
• Set failOnError to false for resilient batch jobs that must always return one record per vendor.
• Use sourceEndpoints to preserve provenance in downstream reports.
• Treat vendor-reported status as one signal. For critical dependencies, combine it with synthetic monitoring of the actual workflow your application depends on.
• If a page only produces a partial result, submit its direct public status-page URL rather than a corporate support or documentation page.

FAQ, disclaimers, and support

Does this independently test vendor uptime? No. It normalizes what vendors publish on their public status pages. Pair it with synthetic or application-level monitoring when independent verification is required.

Why is incident-free percentage null? Some feeds publish incident messages without both start and resolution timestamps. The Actor avoids inventing durations.

Does it access private customer status pages? No. The Actor does not log in, bypass access controls, or access private networks.

Is public status-page collection legal? Public operational notices are generally published for customers to read and subscribe to, but you remain responsible for applicable terms, laws, retention rules, and downstream use.

If a public provider format is not recognized or changes, use the Actor’s Issues tab and include the public status-page URL. Custom provider adapters and larger vendor-intelligence workflows are also available as custom solutions.