Monitor vendor incidents and collect dated SLA evidence

Vendor Status Page & Incident Monitor normalizes public SaaS and cloud status pages into one incident dataset. Use this Statuspage and Instatus incident monitor for SRE alerts, MSP customer reporting, vendor risk reviews and dated evidence for SLA credit requests. Collect incidents, maintenance windows and degraded components without logging in or scraping status page HTML.

Statuspage and Instatus incident monitoring

The Actor reads public JSON status feeds, checks robots.txt and combines recent incident history with current summary notices. The live-tested defaults are Cloudflare Status, OpenAI Status and Linear Status. A successful empty run can mean no matching incidents, an unchanged monitor, a spending limit or unavailable upstream pages. Check RUN_SUMMARY to distinguish them.

What data can you get

Each dataset row represents one incident, maintenance notice or component degradation observation. Each row uses the incident billing event.

Fields	Meaning
id, incidentId	Status host plus native incident ID, and the native ID separately
vendorName, vendorHost, platform	Published page name, canonical input hostname and API format
pageOverallStatus	none, minor, major, critical, maintenance or unknown
title, status, impact, isActive	Redacted title, normalized lifecycle, severity and active flag
affectedComponents	Published component names with personal data redaction
createdAt, updatedAt, resolvedAt	UTC timestamps; unavailable update or resolution times are null
durationMinutes	Minutes from creation to resolution, otherwise null
updatesCount	Number of published updates returned by the endpoint
latestUpdateBody	Optional redacted plain text excerpt, at most 1,000 characters
shortlink, sourceUrl, attribution	Official HTTPS source and vendor attribution
firstSeenAt, changeType	Monitor-only first observation and prioritized change category

Component-only observations use component-<nativeComponentId> as incidentId. Their source is the page root, and their creation time uses the component change timestamp, falling back to its published creation timestamp. They are observations, not vendor-authored incident notices. The Actor does not infer recovery when a component disappears from a later summary.

How to use the vendor status tracker

1. Open the Actor input and enter public status page root URLs or hostnames.
2. Choose the age window, impact and optional title/component keywords.
3. Set a small result limit and run. Empty API input {} uses the verified defaults.
4. Open the dataset or overview table. Export the rows as JSON or CSV.
5. Inspect RUN_SUMMARY for each vendor's availability, cache status, warnings and limits.

{
  "statusPages": ["https://www.cloudflarestatus.com", "https://status.openai.com", "https://linearstatus.com"],
  "activeOnly": false,
  "minImpact": "all",
  "updatedWithinDays": 14,
  "includeUpdateText": false,
  "maxIncidentsPerPage": 15,
  "maxResults": 30,
  "monitorMode": false,
  "requestDelayMs": 750
}

Incident output example

This shortened real observation illustrates the dataset shape. Source status changes over time.

{
  "id": "www.cloudflarestatus.com:575028s1mgk1",
  "vendorName": "Cloudflare Status",
  "vendorHost": "www.cloudflarestatus.com",
  "platform": "statuspage",
  "pageOverallStatus": "major",
  "incidentId": "575028s1mgk1",
  "title": "DTW (Detroit) on 2026-10-26",
  "status": "scheduled",
  "impact": "maintenance",
  "isActive": true,
  "affectedComponents": ["Detroit, MI, United States - (DTW)"],
  "createdAt": "2026-10-25T13:40:40.000Z",
  "updatedAt": "2026-10-25T13:40:40.419Z",
  "resolvedAt": null,
  "durationMinutes": null,
  "updatesCount": 1,
  "shortlink": "https://www.cloudflarestatus.com/incidents/575028s1mgk1",
  "sourceUrl": "https://www.cloudflarestatus.com/incidents/575028s1mgk1",
  "attribution": "Cloudflare Status public status page"
}

Vendor	Notice	Status	Impact
Cloudflare Status	DTW (Detroit) on 2026-10-26	scheduled	maintenance
Cloudflare Status	Kampala, Uganda - (EBB) degradation	investigating	critical

Inputs and filters

Input	Default	Behavior
statusPages	Three verified defaults	1 to 30 unique public HTTPS root URLs; required in the Store editor
activeOnly	false	Excludes resolved, postmortem and completed notices
minImpact	all	all, minor, major or critical; maintenance matches only all
updatedWithinDays	30	Age based on latest update or creation; zero disables age filtering within the recent window
keywords	empty	Case-insensitive OR matching of title and component names
includeUpdateText	false	Adds the latest redacted excerpt
maxIncidentsPerPage	20	1 to 50 newest candidates per vendor, before filtering
maxResults	100	1 to 1,000 rows, hard output cap
monitorMode	false	Emit baseline, then changed versions only
monitorKey	default	Independent persistent watch namespace
requestDelayMs	750	At least 250 milliseconds between requests to the same host

The tiny Store prefill uses 14 days, 15 candidates per vendor and 30 results. Instatus summaries sometimes expose only the last update, so updatesCount is the returned count, not a guaranteed lifetime count. If creation is unavailable in a maintenance summary, its scheduled start is used as createdAt.

Incremental runs / monitoring

Set monitorMode: true and reuse monitorKey across scheduled runs. The first run emits matching notices as new_incident. Later runs emit resolved when a notice enters a terminal state, status_changed for status or impact changes, or update_added for a changed latest timestamp. Only one category is emitted per notice per run, in that order of precedence. firstSeenAt persists for acknowledged versions.

State is kept in a named key-value store, separate from the default dataset. Filters isolate watches; changing filters or monitorKey creates a new baseline. Page lists and row caps do not reset state. A capped first run can leave more new rows for subsequent runs. Update text edits without a timestamp change are not detected.

Schedule one run at a time for a watch. Delivery reservations prevent a second charge for a previously claimed version. If a dataset write has an ambiguous failure, a reserved version can be skipped on retry. This favors duplicate-charge prevention and does not guarantee exactly-once delivery. A one-minute shared cache and error cooldown reduce repeated upstream traffic. Data can be up to one minute old. Purging local default storage clears the default dataset, not the named watch state.

Pricing

Planned price: $2.00 per 1,000 incidents. One dataset row is one incident event, including maintenance, component observations and changed incident versions. Unchanged monitor checks emit no rows. The final price is shown on the Store page. The run also has an apify-actor-start event. Check the Store pricing for its current price. The Actor checks the remaining event allowance before dataset writes and stops gracefully when the spending limit is reached. This source package does not configure Store pricing.

Scheduling and integrations

Use Apify schedules for regular checks and webhooks for run completion. Read datasets and RUN_SUMMARY with the Apify API. Connect results to Make, Zapier or n8n for alerts, vendor risk reports and evidence archives. AI agents can consume results through Apify MCP integrations. This Actor collects data; it does not send alerts or submit credit claims itself.

Is it legal?

The Actor uses public official JSON endpoints, no login, no cookies and no proxies. It respects each target's robots.txt and refuses restricted endpoints. Text passes through personal data redaction; author objects, emails and phone fields are not copied into the schema. Automated redaction can suppress useful terms and cannot certify anonymity. Review evidence before sharing it. You are responsible for complying with vendor terms and your intended use.

This Actor and its output are not legal advice. A public incident is not proof that a specific contract, tenant or region qualifies for SLA credits. Contract terms and submission deadlines require independent review.

Limitations

• This is a recent-window monitor, not a complete historical archive. Each vendor provides at most 50 retained candidates, including current maintenance and component observations. No historical pagination is performed.
• Age and keyword filters apply after the per-vendor candidate cap. Increase that cap if current maintenance or components crowd out older incidents.
• Duration runs from published creation to resolution. It is not measured downtime, monthly uptime or a contractual SLA calculation.
• Summary maintenance coverage varies. Completed maintenance absent from a summary is not fetched from separate maintenance history routes.
• platform describes the public response format. A vendor can serve Statuspage-compatible JSON through different hosting software.
• Instatus pages must expose the documented legacy summary route. Instatus history is disabled because the legacy history route has no verified public documentation; RUN_SUMMARY reports summary-only coverage. Authenticated management APIs and current v3-only routes are outside this Actor's scope.
• Robots restrictions, redirects, network failures, schema changes and rate limits can reduce coverage. Unsafe API redirects are refused. Only an absent robots.txt (404 or 410) means no published restriction.
• All unavailable targets produce a successful zero-row run with upstream_unavailable in RUN_SUMMARY. Invalid input and dataset or persistent watch storage errors fail the run.
• Collection stops within a 45-second budget and reserves time before a platform timeout. Inspect time_limit before assuming a scan was complete.

FAQ

Why did a status page with a working API produce no rows? Its robots policy can disallow automated API access. Other causes include filters, a candidate cap, an unchanged watch or upstream failure. RUN_SUMMARY records the distinction.

Does activeOnly exclude scheduled maintenance? No. Scheduled, in-progress and verifying maintenance remain active until completed.

Can I claim SLA credits automatically? No. Use the dated observations as a starting point for review against your own agreement and service telemetry.

Can I monitor arbitrary websites? No. Inputs must be public HTTPS status page roots exposing supported JSON routes. Private addresses, credentials, nonstandard ports and arbitrary paths are rejected.

What happens when my spending limit is reached? Collection stops gracefully. Only delivered versions are acknowledged in monitor state, subject to the reservation limitation described above.

Support

Use this Actor's Issues tab on Apify with the input, RUN_SUMMARY and a description of the expected result. Remove sensitive data first.

Trademark disclaimer

Cloudflare, OpenAI, Linear, Atlassian, Statuspage, Instatus, Apify, Make, Zapier and n8n are trademarks of their respective owners. This Actor is not affiliated with, endorsed or sponsored by any of the named trademark owners.