A status transparency directory records whether AI providers expose usable incident history, rather than ranking them by a green status badge. Teams need to know which components an incident covers, how updates are dated, and whether yesterday’s problem remains visible after service recovers. This guide builds that directory with evidence a colleague can revisit.
Primary sources checked on 8 October 2026. Worked examples and sample records below are illustrative; they do not represent product tests or real customer findings.
Define what counts as status history
A current-status page and an incident archive answer different questions. The first describes what the provider reports now; the second can show when a component was degraded and how the investigation progressed. For this directory, count history only when you can open a past incident or dated maintenance record. A page that says all systems operational is not enough.
Choose the components relevant to your team: consumer chat, API inference, file uploads, authentication, coding agent, or billing. Providers may combine several components or use different names. Write the names as they appear and add your own mapping in a separate column. This avoids confusing an API interruption with a consumer-app problem simply because both belong to the same company.
Find the official page and its history route
Start from the provider’s documentation or support site and follow its status link. An independent outage tracker can be useful for discovery, but it should not substitute for the official page in a directory of vendor disclosures. Verify the destination domain and retain the route you used to reach it. Search results can contain stale domains or unofficial mirrors.
Claude’s official history page exposes incident navigation and links to Atom and RSS feeds. Record those as observed features, not as a guarantee that every disruption will appear. Open a dated incident in your own research session before recording its details. If the history interface requires scripts that your reader cannot load, mark that access limitation and keep the directly accessible official links.
Capture transparency fields without inventing uptime
Use one row per provider and include the official URL, history URL, components, incident timestamps, update visibility, subscription options, and observation date. Add a field for the earliest record you actually inspected. That is an observed boundary, not necessarily the beginning of the archive. A paginated interface may hold older events beyond the first screen.
Do not calculate availability from a handful of incident entries. The page may omit low-impact failures, aggregate regions, or describe partial degradation without a complete affected interval. Record whether the provider publishes uptime methodology separately. If you need an availability metric, define the monitoring scope and use measurements designed for that purpose rather than treating status-history disclosure as a complete performance dataset.
Test whether a past event remains usable
Select a fictional review window such as the previous calendar month and inspect several accessible records. Note whether each has a stable link, an initial report time, updates, and a resolution statement. Copy a short description of the component and impact into the directory. Avoid copying the entire incident narrative; the stable link should remain the authoritative reference.
Check timezone labels carefully. A local support complaint may use your office timezone while the status page uses UTC or the viewer’s locale. Preserve the original timestamp and add a normalized value only when the timezone is known. Otherwise state that the comparison remains approximate. A precise-looking conversion from an unlabeled time can make unrelated events appear to match.
Distinguish disclosure gaps from reliability claims
Suppose Provider A has a searchable incident archive and Provider B has only a current banner. The supported directory finding is that A exposes the inspected historical records and B’s public history was not found through the documented search. It does not establish that A is less reliable because it lists more incidents, or that B has had no outages.
Use explicit labels: official history found, current status only, access restricted, or not found after documented checks. Include the checks made and a contact route where available. An absent search result is not evidence of an absent capability. Give the provider’s official support pages a fair inspection before concluding that the history is not publicly accessible.
Maintain the directory as an operational resource
Ask a teammate to use the directory during a simulated upload failure. They should reach the correct component without guessing, find a historical record, and understand which observations are current. If they land on an unrelated API page, fix the component mapping. Store the directory alongside your own troubleshooting checklist so provider disclosure can be compared with local logs.
Recheck links on a regular review date and after a provider rebrands its support system. Preserve old routes as historical references but highlight the current destination. Keep subscriber features separate from public history, because an email feed may provide notifications without making the archive accessible. The finished directory should reduce incident triage time while remaining careful about what public status data can and cannot prove.
Review and preserve the finished status transparency directory
Before handing over the result, perform a review that starts from the evidence rather than the generated prose. Pick a clearly supported item, a disputed item, and an item with missing information. Write the expected treatment of each before reading the proposed conclusions. Then open the cited originals and compare the result with those expectations. Check the surrounding text, headings, dates, and qualifications, because a citation can point to the correct document while supporting a narrower statement.
Ask a colleague to use the finished deliverable without your explanation. They should be able to locate the original records, identify unresolved questions, and understand which statements are direct evidence and which are your interpretation. Revise any place where they must guess. Keep the reviewed output, source manifest, prompt, and correction history together. Record the review date and the event that should trigger another check. When a source changes, preserve the earlier assessment and explain which conclusions were affected rather than silently replacing the evidence.
Do not equate an empty result with the absence of a problem. Check that all intended inputs were included and readable. Explain exclusions and merged records. A useful handover makes incompleteness visible and assigns a next action to the person who can resolve it.
Frequently asked questions
Does a green badge prove no customers are affected?
No. It reports the provider’s displayed status for its chosen components and scope; your own workflow may still fail.
Can incident counts rank providers?
Not fairly without matching disclosure policies, component scope, time windows, and impact measurement.
Are independent trackers primary sources?
They are independent observations. Keep them separate from a directory specifically documenting official provider disclosures.
What if history will not load?
Record the access limitation, retain official links, and avoid claiming that an inaccessible archive does not exist.
How often should I update the directory?
Choose a practical review interval and revisit it when support domains, component names, or provider products change.
