每个AI开发者都遇到过这种情况：你的应用抛出503错误，用户不断追问你，而你打开了12个浏览器标签页——OpenAI状态页面、Anthropic状态页面、GitHub Copilot健康页面、三个不同的Discord服务器——试图弄清楚这是你的问题还是他们的？这就是我们着手解决的问题。Prismix将77个AI服务的状态聚合在一个地方。经过六周的生产环境运行，我们学到了一些可能为你节省时间的经验。
问题比你想象得更严重
AI API的故障方式与传统基础设施不同。它们以奇怪、局部的方式失效：
- 降级性能——通过健康检查，却让你的产品感觉像是坏掉了
- 区域性宕机——OpenAI美国东部宕机而欧盟正常，所以一半用户受到影响
- 静默速率限制级联——API返回429，但其状态页面在接下来20分钟内仍显示"运行正常"
- 事件滞后——服务提供商通常在工程师已经察觉后10-30分钟才发布状态更新
官方的状态页面在设计上是乐观的。它们是对外沟通工具，而非实时工程仪表盘。
77个状态页面聚合后的全貌
当同时监控77个AI服务时，模式很快显现。OpenAI是最受关注的服务。模式几乎总是：调查中 → 已确认 → 监控中 → 已解决，通常在45-90分钟内。调查阶段是大多数开发者恐慌的时候——看起来糟糕，但通常无需你采取行动就会解决。
与API使用量的增长相比，Anthropic的运行明显更干净。事件更少、更短。
长尾部分很有趣。像Replicate、Runway、ElevenLabs和Suno这类服务的事件模式与OpenAI完全无关——它们是真正的独立故障域，适合用于冗余设计。
"无声降级"问题确实存在。我们多次看到某个服务显示"运行正常"，而我们的正常运行时间探测却在超时。这就是为什么Prismix会为每个服务显示延迟迷你曲线——状态页面捕获已公告的事件，探测则捕获真实的事件。
Prismix 做了什么（以及为什么免费）
Prismix 从各服务的官方状态页获取数据，并补充了单个状态页所没有的信息：
- 按服务延迟探测 — 24 小时迷你趋势图，显示实际响应时间，而不仅仅是已公布的事故。
- 跨服务事故时间线 —
/incidents页面将所有 77 个服务的事件整合到一个可滚动的信息流中，便于事后分析。 - 公共 REST API —
GET /api/v1/statuses以 JSON 格式返回当前状态，无需认证、无速率限制、CORS 开放，永久免费。 - MCP server — 可以问 Claude "OpenAI 现在宕机了吗？" 并获得实时回答。只需在
claude_desktop_config.json中添加一行配置。
它之所以免费，是因为运行在 Cloudflare 的免费套餐上（Workers + KV）。Pro 套餐（$10/月）增加了邮件/Webhook 告警功能，但核心仪表盘保持免费。
技术细节
技术栈为 Astro 5 SSR + Cloudflare Workers + KV。KV 的免费套餐每天提供 10 万次读取，但仅支持 1 千次写入。每 5 分钟运行一次的状态刷新定时任务采用条件写入——仅在内容实际发生变化时才写入。这使写入量从每天约 8,400 次降到了约 600 次。监控基础设施必须运行成本低廉，否则保持免费的意愿就会消失。
我们尚不确定的事
六周下来，有些问题我们确实还没把握：
- 哪些服务被遗漏了？ 当前列表覆盖 LLM API 和热门 AI 工具，但很可能漏掉了你技术栈中的某些服务。
- 延迟探测有用吗？ 它能告诉你"这个服务现在很慢"，但无法回答"相比以往有多慢"——目前还没有历史基线。
- 什么功能才能让你每天都用？ Slack 机器人？PagerDuty 集成？终端里的小工具？
如果其中任何一点引起了你的共鸣，欢迎留言。访问 prismix.dev。Prismix 还提供了包含 500+ 个服务器的 MCP server 目录以及精选 AI 新闻源——但我们最想听到反馈的还是状态监控这一部分。