Service Status Checker - Is It Down? Status Page & Outage API

When your AI agent or script gets an error from GitHub, OpenAI, AWS, Twilio or another service, ask this before you debug your own code: what does that service's official status page say right now? One call, one row per service: officialStatus (operational, degraded, partial_outage, major_outage or maintenance), the page's own wording, the active incidents with their latest update, the components that are not operational, and maintenance in progress or scheduled.

It reports what the provider's official status page says. It does not test the service itself. A status page can lag behind a real outage or never mention a small one, so isOperational: true means "the status page reports no problem", not "verified working". When a status page cannot be read, the row says so and gives no status; it never falls back to "operational".

Example

Input:

{ "services": ["api.openai.com", "Twilio", "GitHub"] }

Output (shortened, one row per service):

[
 {
  "query": "api.openai.com",
  "service": "OpenAI",
  "status": "ok",
  "officialStatus": "operational",
  "officialStatusDescription": "All Systems Operational",
  "isOperational": true,
  "activeIncidentCount": 0,
  "activeIncidents": [],
  "affectedComponents": [],
  "upcomingMaintenanceCount": 0,
  "statusPageUrl": "https://status.openai.com/",
  "readVia": "https://status.openai.com/api/v2/summary.json",
  "checkedAt": "2026-09-25T06:38:08.272Z"
 },
 {
  "query": "Twilio",
  "service": "Twilio",
  "status": "ok",
  "officialStatus": "degraded",
  "officialStatusDescription": "Partially Degraded Service",
  "isOperational": false,
  "activeIncidentCount": 11,
  "activeIncidents": [
   {
    "id": "4vqcpc3zd4mq",
    "title": "User Authentication Identity Gateway API Failure Increase and High Latency for Verizon in United States",
    "impact": "minor",
    "status": "investigating",
    "startedAt": "2026-09-25T06:34:12.462Z",
    "updatedAt": "2026-09-25T06:34:12.570Z",
    "latestUpdate": "Twilio customers may be experiencing User Authentication Identity Gateway API failure increase and Gateway API high l...",
    "latestUpdateAt": "2026-09-25T06:34:12.567Z",
    "affectedComponents": [
     "Lookup SIM Swap",
     "Legacy Identity MatchAndAttributes"
    ],
    "url": "https://stspg.io/jww5m96l8ng4"
   }
  ],
  "affectedComponents": [
   {
    "name": "Bulk Export",
    "status": "degraded_performance",
    "group": ""
   },
   {
    "name": "SMS Long Code, North America",
    "status": "under_maintenance",
    "group": ""
   },
   {
    "name": "SMS Short Code, North America",
    "status": "degraded_performance",
    "group": ""
   }
  ],
  "upcomingMaintenanceCount": 31,
  "statusPageUrl": "https://status.twilio.com/",
  "readVia": "https://status.twilio.com/index.json + https://status.twilio.com/",
  "checkedAt": "2026-09-25T06:38:08.354Z"
 },
 {
  "query": "GitHub",
  "service": "GitHub",
  "status": "ok",
  "officialStatus": "operational",
  "officialStatusDescription": "All Systems Operational",
  "isOperational": true,
  "activeIncidentCount": 0,
  "activeIncidents": [],
  "affectedComponents": [],
  "upcomingMaintenanceCount": 0,
  "statusPageUrl": "https://www.githubstatus.com/",
  "readVia": "https://www.githubstatus.com/index.json + https://www.githubstatus.com/",
  "checkedAt": "2026-09-25T06:38:08.410Z"
 }
]

Leave the input empty and the example service OpenAI is checked (the row says isExampleInput: true).

What you can put in

• a service name: GitHub, OpenAI, Claude, Stripe, AWS, Google Cloud, Vercel (exact name, a known alias, or a prefix that matches only one service)
• the domain or API host you called: api.openai.com, api.github.com, hooks.slack.com (matched to the service that owns the domain)
• a status page URL: https://www.githubstatus.com

A domain that is not in the verified list is looked up at the usual places (status.<domain>, <name>status.com, <name>-status.com, status.<name>.com, status.<name>.io) and used only when a status page this Actor can read answers there (source: "discovered").

Services in the verified list (407 status pages, all read on 2026-09-25)

1Password, Ably, Affirm, Afterpay, Airbyte, Aircall, Airtable, Airwallex, Aiven, Akamai, Alloy, Amplitude, Anaconda, Anthropic (Claude), api.video, Apify, Apigee, Apollo.io, AppCenter, Appcues, Appwrite, Asana, AssemblyAI, Atlassian, Atlassian Statuspage, Autodesk, Avalara, AWS, Axiom, Bandwidth, Basecamp, Baseten, Better Stack, BigCommerce, Bird (MessageBird), Bitbucket, Bitly, Bitrise, Bland AI, Bolt, Box, Braintrust, Branch, Braze, Brevo, Brex, Browserless, BrowserStack, Bubble, Buffer, Bugsnag, Buildkite, Bunny.net, Calendly, Canva, Cartesia, Cerebras, Chainguard, Chargebee, Chroma, Chromatic, CircleCI, Clearbit, Clerk, ClickHouse Cloud, ClickSend, Close, Cloudflare, Cloudinary, Cloudsmith, Coda, Codecov, Codemagic, CodeSandbox, Cohere, Coinbase, Confluence, Confluent, Contentful, Contentsquare, Convex, Coralogix, CoreWeave, Courier, Cribl, Crowdin, Cursor, Cypress Cloud, D-ID, Daily, Dashlane, Databricks, Datadog, Datadog EU, dbt Cloud, Deepgram, DeepSeek, Deno Deploy, Depot, Descope, Descript, Dialpad, DigitalOcean, Discord, Discourse, DNSimple, Docker, Doppler, Drata, Dropbox, Dropbox Sign, Dwolla, Dynatrace, Earthly, EasyPost, Elastic Cloud, ElevenLabs, Embrace, Epic Games, Exa, Expensify, Expo, Fastmail, Fern, Figma, Filestack, Firebase, Firecrawl, Fireworks AI, Flagsmith, Flutterwave, Fly.io, Frame.io, Framer, FreshBooks, Front, Frontegg, FullStory, FusionAuth, Gandi, Gemini (exchange), Ghost, GitBook, GitGuardian, GitHub, GitLab, Gitpod (Ona), Gladia, Gladly, GoCardless, GoDaddy, Gong, Google Cloud, Google Workspace, Gorgias, Grafana Cloud, Grammarly, Groq, Gusto, HackerOne, HashiCorp (HCP Terraform), Hashnode, Hasura, Heap, Helicone, Help Scout, Heroku, Hex, HeyGen, Honeycomb, Hookdeck, Hootsuite, Hostinger, Hotjar, HubSpot, Hugging Face, IFTTT, imgix, incident.io, Increase, InfluxData, Inngest, Intercom (Fin), JFrog, Jina AI, Jira, Jotform, Jumio, Kinsta, Kit (ConvertKit), Klarna, Klaviyo, Knock, Kong Konnect, Kraken, Kustomer, Lambda Labs, LangSmith, LastPass, LaunchDarkly, Let's Encrypt, Lightstep, Linear, Linode (Akamai Cloud), Lithic, Liveblocks, LiveKit, Loggly, LogRocket, Logz.io, Lokalise, Loom, Loops, Lovable, Lucid, Luma AI, Lumigo, MagicBell, MailerLite, Mailgun, Mailjet, Mailosaur, Make, Mapbox, Marqeta, Medium, Meilisearch, Mend, Mercury, Metabase, Mezmo, Microsoft Azure, Mintlify, Miro, Mixpanel, Modal, Modern Treasury, Mollie, Monday.com, MongoDB Atlas, Mural, Mux, Namespace, Neon, Netlify, New Relic, ngrok, Nhost, Notion, Novu, npm, Nx Cloud, OneSignal, Onfido, OpenAI, Opsgenie, Optimizely, Paddle, PandaDoc, Pantheon, Paperspace, Papertrail Logs, Patreon, Payoneer, Paystack, Pendo, Percy, Perplexity, Persona, Phrase, Pinecone, Pipedream, Plaid, PlanetScale, Plausible, Plivo, Portkey, Postman, Postscript, Prisma, Prismic, Productboard, PubNub, Pusher, PyPI, Qdrant, QuickBooks, Raycast, ReadMe, Recharge, Recurly, Reddit, Render, Resend, Retell AI, Retool, Rev.ai, RevenueCat, Rippling, Roblox, Rollbar, RubyGems, Runway, Salesloft, SambaNova, Sanity, Sauce Labs, Scaleway, Secureframe, Segment, Semgrep, SentinelOne, Sentry, SerpApi, Shippo, ShipStation, Shopify, Sinch, SingleStore, Sketch, Slack, Smartling, Smartproxy (Decodo), Smartsheet, Snowflake, Snyk, Socket, Socure, SonarCloud, Sourcegraph, SparkPost, Speakeasy, Speechmatics, Spline, Split, Sprout Social, Square, Squarespace, Stability AI, Statsig, StatusCake, Stoplight, Stream, Stripe, Stytch, Sumo Logic, Sumsub, Supabase, SurveyMonkey, Svix, Synthesia, Synthflow, Tabnine, Tailscale, Talkdesk, Tavily, TaxJar, Telnyx, Temporal Cloud, Textmagic, Todoist, Together AI, Transifex, Travis CI, Trello, Trigger.dev, Turso, Twilio, Twingate, Twitch, Tyk, Typeform, Unit, Uploadcare, Upstash, Userpilot, v0, Vanta, Vapi, Vectara, Vercel, Veriff, Vimeo, Vimeo OTT, Warp, Wasabi, Webflow, Weights & Biases, Windsurf, Wise, Wistia, Wix, Wiz, WorkOS, Writer, Xata, Xendit, Xero, xMatters, Yotpo, Zapier, Zed, Zilliz, Zoom, ZoomInfo, Zuplo, Zyte.

Also known, but their status pages have no machine-readable feed this Actor can read yet (you get a free row with the status page URL): Adobe, Adyen, Agora, Algolia, Auth0, Backblaze, Bitwarden, Cal.com, ConfigCat, Crisp, DatoCMS, Deel, Evernote, FireHydrant, Fivetran, Freshping, Freshworks (Freshdesk), Gumroad, Hetzner, Highlight, IBM Cloud, Jasper, JetBrains, Langfuse, Lemon Squeezy, LiteLLM, Mailchimp, Midjourney, Obsidian, Okta, OpenRouter, Outreach, PagerDuty, Pingdom, Pipedrive, Pitch, Plunk, Postmark, Railway, Razorpay, Redis Cloud, Rime, RingCentral, Salesforce, ScrapingBee, StackBlitz, Storyblok, Unity, UptimeRobot, Vast.ai, VWO, Webex, Whimsical, Zendesk.

How each status page is read

Status page type	Pages	What is read
Atlassian Statuspage	272	/index.json of the page (the page's own JSON), or the page itself if that is not allowed
incident.io	73	/api/v2/summary.json, plus /proxy/<host> for upcoming maintenance
Better Stack	28	/index.json
Instatus	17	/summary.json and /v2/components.json
status.io	10	the public status API api.status.io/1.0/status/<page id>
Google Cloud, Google Workspace, Firebase	3	the official dashboards' incidents.json (open incidents only)
AWS	1	the AWS Health Dashboard's current events
Heroku	1	its public status API
Microsoft Azure	1	the official Azure status RSS feed
Slack	1	its public status API

robots.txt is followed for every request. Atlassian Statuspage pages disallow /api/ for all crawlers, so this Actor never reads their /api/v2/summary.json; it reads /index.json (not under /api/) or the page. If a site's robots.txt cannot be read (5xx or no answer), nothing else is requested from it (RFC 9309). A bot check (CAPTCHA or JavaScript challenge) is never solved or retried.

Status values

officialStatus	Meaning (from the page's own indicator)
operational	The page reports no problem
degraded	Minor issue or degraded performance (Statuspage "minor")
partial_outage	Part of the service is down (Statuspage "major"). AWS and Google Cloud report any open regional outage this way
major_outage	Major outage (Statuspage "critical")
maintenance	Under maintenance

Components use operational, degraded_performance, partial_outage, major_outage, under_maintenance. Some Statuspage pages list only component groups in their JSON; then affectedComponents names the group, and each incident's affectedComponents names the exact components.

Monitoring mode (only changes)

Set onlyChanges: true (and optionally a watchName) and run it on a schedule. The first run returns every service once (changeType: "first_check"). After that a service comes back only when its status page changed (changeType: "changed"), with changes such as official status operational -> degraded, incident started: ..., incident updated: ..., component: API is partial_outage or new scheduled maintenance: ..., and previousOfficialStatus. A service that was read but did not change is not returned and costs only the check fee. A change is reported only for parts that were read in full both times: a status page that could not be read, or was only partly read (for example its JSON but not the page), never changes what is remembered for the missing parts and is never reported as a change. For upcoming maintenance only a newly scheduled window counts as a change (windows that pass or are cancelled do not).

Input

Field	Default	What it does
services	(example: OpenAI)	Service names, domains or status page URLs
onlyChanges	false	Monitoring mode: return a service only when its status page changed
watchName	empty	Separate memory per watch (setting it turns monitoring on)
resetMonitoringState	false	Forget this watch's memory first
includeAllComponents	false	Also return every component with its status (components)
includeUpcomingMaintenance	true	Return scheduled maintenance (up to 20, count in upcomingMaintenanceCount)
discoverUnknownDomains	true	Look for status pages of domains not in the list
maxServices	200	Services per run (up to 500)
useProxy	true	Retry through a proxy on 403 or 429 (never for a bot check)

Output columns

query, service, statusPageUrl, statusPageProvider, source (directory or discovered), status (row status: ok or why not), officialStatus, officialStatusDescription, isOperational, hasActiveIncident, activeIncidentCount, incidentListComplete (false only when an Atlassian Statuspage page could be read as JSON but not as a page; its JSON lists only the 10 most recent incidents, so an older unresolved incident may be missing), activeIncidents (id, title, impact, status, startedAt, updatedAt, latestUpdate, latestUpdateAt, affectedComponents, url), affectedComponents (name, status, group), componentCount, components, activeMaintenances, upcomingMaintenances (title, status, startsAt, endsAt, window, affectedComponents, url), upcomingMaintenanceCount, pageUpdatedAt, readVia (the exact URL that was read), checkedAt, changeType, changes, previousOfficialStatus, isExampleInput, suggestions, note.

Free rows (status other than ok): not-found (with suggestions), unsupported (status page known, no readable feed), duplicate (the same status page was already in your list under another name, for example GitHub and github.com), unreadable, robots-disallowed, bot-check, bad-input, budget-reached, not-checked (over maxServices, or the run was about to reach its timeout).

Measured

All numbers below were measured on 2026-09-25.

• Verified list: all 407 status pages were read with this Actor's own reading code: 407 of 407 answered. In one production run of all 407 services (256 MB memory) 406 came back in 145 seconds; one page did not answer in time and came back as a free unreadable row.
• From Apify's servers: 16 status endpoints (Statuspage, incident.io, Better Stack, Instatus, status.io, Google Cloud, AWS, Azure, Slack, Heroku) answered 48 of 48 direct requests, 16 of 16 through the datacenter proxy and 16 of 16 through the residential proxy.
• Against the live pages in a browser (10 services, same minute as a production run): on the 6 Atlassian Statuspage pages the unresolved incidents and the non-operational components matched the page exactly (Twilio 11 incidents and 14 components, Kraken 7 and 9, Supabase, Xero, Snowflake, GitHub). On the 4 others (Stripe, Cloudflare, OpenAI, Hugging Face) every incident title was on the page and the operational wording matched.
• Why the page is read too: an Atlassian Statuspage page's JSON lists only its 10 most recent incidents. Twilio's page showed 11 unresolved incidents while the JSON had 2, and Supabase's page showed an unresolved incident open since 2026-08-14 that was not in the JSON at all.
• Speed and cost: a run for 1 to 3 services took about 3 seconds and about $0.0001 of platform usage at 256 MB.

Pricing

Pay per event:

• Run start: $0.004 once per run that read at least one status page. Not charged when nothing could be read.
• Service status returned: $0.0055 per ok row ($5.50 per 1,000).
• Unchanged service check (monitoring mode only): $0.0015 per service that was read and had not changed ($1.50 per 1,000). No row is returned for it.

These are the free-plan prices; paid Apify plans pay less per event. One call for one service costs $0.0095. Monitoring 10 services every 5 minutes for 30 days (8,640 runs) costs about $34.56 in start fees plus $1.50 per 1,000 unchanged checks (about $129.60 if nothing ever changes), plus $0.0055 for each change returned.

Rows that say a service was not found, is not supported, could not be read, or was stopped by your run's charge limit are free. If the run's maximum total charge has no room for the start fee plus one row, nothing more is charged.

Use it from an AI agent (MCP)

Add it to your agent through the Apify MCP server (https://mcp.apify.com) and call it with one service per call, for example {"services": ["api.openai.com"]}, when a request to that service fails.

Limits

• It reports the official status page, not a live test. operational means "not reported".
• 407 status pages are in the verified list; others are found only when they sit at a usual location and are one of the five supported page types.
• Custom-built status pages (Salesforce, Okta, Zendesk, Mailchimp, Auth0, IBM Cloud and the others listed above) are not read.
• Incidents and maintenance lists are capped at 20 per row (the counts are complete).
• Monitoring memory is per watch. Do not run the same watch twice at the same moment: both runs can return (and charge for) the same change, and they can overwrite each other's memory (Apify key-value stores have no atomic update).
• A run stops starting new services 30 seconds before its timeout and says how many were not checked; they are not charged.

Support

Found a status page that is read wrongly, or a service you want added? Open an issue on the Issues tab with the service name and its status page URL.