When something breaks, more people now ask ChatGPT, Claude or Perplexity “is it down?” before they open a status page. Those answers can only use what an AI crawler can read, and most AI crawlers fetch raw HTML without running JavaScript. So we tested 30 well-known SaaS status pages the same way, to see what an AI can actually learn from them.
Key findings
- 25 of 30 pages (83%) showed their current status to a crawler that doesn't run JavaScript.
- 5 of 30 (17%) showed nothing useful: Stripe returned only “Loading...”, Heroku, Datadog and Zendesk returned an empty JavaScript shell, and Cloudflare showed no component statuses. An AI asked whether these services are down can't confirm it from the status page.
- Feeds can rescue an unreadable page: Heroku and Datadog both publish a working RSS or Atom feed, so a tool that finds the feed can still read their incidents.
- Every Atlassian Statuspage and incident.io page we tested was readable (20 of 20). All five unreadable pages showed no provider, which usually means a custom or self-built page.
- incident.io pages show status but hide history: on all 4, past incidents sit behind a “View history” link instead of on the main page.
- 24 of 30 (80%) publish an RSS or Atom feed, the simplest machine-readable way for tools and agents to follow incidents. 24 of 30 showed a subscribe option in their HTML.
- 2 pages served our crawler content from 2022–2024 (Fastly and Notion), which suggests an old or cached version is being shown to crawlers.
Results: what a non-JavaScript crawler sees on 30 SaaS status pages
| Company | Provider shown on page | Current status readable | Recent incidents on main page | Subscribe option | RSS / Atom feed |
|---|---|---|---|---|---|
| GitHub | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| OpenAI | incident.io | Yes | Link only | Yes | Yes |
| Cloudflare | None shown | No | None listed | Yes | Yes |
| Atlassian | Atlassian Statuspage | Yes | None in period | Yes | Yes |
| Slack | None shown | Yes | Link only | Yes | Yes |
| Dropbox | Atlassian Statuspage | Yes | None in period | Yes | Yes |
| Discord | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Twilio | None shown | Yes | Yes | Yes | Yes |
| Stripe | None shown | No (“Loading...”) | No | No | None found |
| Shopify | Atlassian Statuspage | Yes | Yes | Yes | None found |
| Notion | None shown | Yes | Dates only, out of date | No | Blocked by robots.txt |
| Figma | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Linear | incident.io | Yes | Link only | Yes | Yes |
| Netlify | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| DigitalOcean | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Heroku | None shown | No (JavaScript only) | No | No | Yes (page unreadable, feed works) |
| Datadog | None shown | No (title only) | No | No | Yes (page unreadable, feed works) |
| HubSpot | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Mailchimp | None shown | Yes | Yes | Yes | None found |
| Fastly | None shown | Yes | Out of date | No | None found |
| Supabase | incident.io | Yes | Link only | Yes | Yes |
| Render | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Postman | Atlassian Statuspage | Yes | None in period | Yes | Yes |
| Zoom | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Intercom (Fin) | incident.io | Yes, on region pages (main page is a region picker) | Link only | Yes | Yes |
| Vercel | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Sentry | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Claude (Anthropic) | Atlassian Statuspage | Yes | Yes | Yes | Yes |
| Zendesk | None shown | No (empty without JavaScript) | No | No | Not checked |
| Asana | Atlassian Statuspage | Yes | Yes | Yes | Yes |
Results by status page provider
| Provider shown | Pages tested | Current status readable | Incident history on main page | RSS / Atom feed |
|---|---|---|---|---|
| Atlassian Statuspage | 16 | 16 of 16 | 13 of 16 (3 had no recent incidents) | 15 of 16 |
| incident.io | 4 | 4 of 4 | 0 of 4 (link to history page) | 4 of 4 |
| None shown (custom or unbranded) | 10 | 5 of 10 | 2 of 10 (2 more showed out-of-date history) | 5 of 10 (2 not checked) |
| All pages | 30 | 25 of 30 (83%) | 15 of 30 | 24 of 30 (80%) |
Why this matters for AI search
A status page has one job: tell people whether your product works right now. When that question goes to an AI assistant instead of a browser, the assistant reads your page the way a crawler does. If the status only appears after JavaScript runs, the AI sees an empty page and falls back to social posts, outage trackers or guesswork, and it may tell your customers that everything is fine during an outage.
Server-rendered status pages avoid this: the status, the components and recent incidents are in the HTML from the first byte. We cover the technical side in why server-side rendering matters for status page SEO and the AI side in status pages in the age of AI search.
Check your own status page in two minutes
- Fetch it without JavaScript: run curl https://status.yourcompany.com and search the output for your overall status line and a component name. If they aren't there, AI crawlers can't see them either.
- Put recent incidents on the main page, not only behind a history link, so a single fetch answers “was there an outage today?”.
- Offer an RSS or Atom feed so tools, agents and customers can follow incidents without scraping.
- Allow AI crawlers in robots.txt (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot) on your status page domain.
- Make sure crawlers get the live page, not a cached or fallback version with old dates.
Statusentry status pages are server-rendered, so the current status, services and incidents are in the HTML for every crawler. You can check our demo status page with the same curl test, or create a free status page.
Methodology
- We picked 30 public status pages of well-known SaaS and developer tools.
- On November 10, 2026 we fetched each page without running JavaScript, the way most AI crawlers read pages, and recorded what the HTML alone contains. Zoom and Intercom redirect to zoomstatus.com and finstatus.com; we tested those pages.
- “Current status readable” means an overall status line or component names with their status appeared in the HTML. “Provider” is the “Powered by” text or link on the page.
- Feeds were checked at the provider's standard feed URLs (for example /history.rss on Atlassian Statuspage and /feed.rss on incident.io). “None found” means none of the URLs we tried returned a feed; one may exist elsewhere.
- This is one snapshot. Pages change with each deploy, and incident history depends on whether there were recent incidents.
FAQ
Can ChatGPT and other AI assistants read status pages?
Only if the status is in the page's HTML. Most AI crawlers don't run JavaScript, so a status page that loads its status with JavaScript looks empty to them. In our November 2026 test, 25 of 30 SaaS status pages showed their status without JavaScript and 5 did not.
Which status pages couldn't be read without JavaScript?
In our test, Stripe returned only “Loading...”, Heroku, Datadog and Zendesk returned an empty JavaScript shell, and Cloudflare showed no component statuses. Every Atlassian Statuspage and incident.io page we tested was readable.
How do I check whether AI crawlers can read my status page?
Run curl on your status page URL and look for your overall status line and a component name in the output. If they're missing, crawlers that don't run JavaScript can't see them.
