ai-watch.dev

AIWatch 是一个对 46 个 AI 服务（如 Claude、ChatGPT、Gemini、Cursor、Codex 等）做实时状态监控的网站，用来查看某个 AI 服务是否宕机、追踪其正常运行时间和故障事件。它把每个服务的可用性拆成三类信息：当前状态、历史正常运行时间、以及具体故障事件记录。理解这三者的区别，就能判断“现在能不能用”和“这个服务最近稳不稳”。

服务状态：此刻能不能用

服务状态是页面上最直接的信号，反映监控系统对目标服务当前可用性的判断。常见取值及含义：

• 正常（Operational）：服务按预期响应，未检测到异常。
• 宕机（Down / Outage）：服务无响应或返回错误，当前不可用。
• 降级（Degraded）：服务仍能访问，但性能或部分功能异常，例如响应变慢、某些功能报错。

判断时要注意两点：状态是监控方的检测结果，可能与你本地网络、账号或区域限制造成的“打不开”不一致；降级状态意味着“能用但别指望稳定”，适合先做非关键任务。

正常运行时间：一段时间内的可用比例

正常运行时间（uptime）是把一段时间内的可用情况折算成比例，用来看服务的长期稳定性，而不是某一刻的状态。

查看方式通常是：在服务条目上找到 uptime 或历史时间轴区域，观察按天/按小时排列的色块或百分比。色块颜色一般对应上面几种状态，绿色代表正常，其他颜色对应降级或宕机。

使用时注意：

• uptime 高不代表你此刻能用，它只说明历史可用比例高。
• 统计窗口不同（如 24 小时、7 天、30 天），同一个服务的数字会不一样，比较时要用相同窗口。
• 短时间故障对长期 uptime 的影响可能很小，但对正在赶任务的你影响很大，所以要结合下面的故障事件一起看。

故障事件：发生了什么、持续多久

故障事件（incidents）是对每一次异常的具体记录，回答“什么时候出的问题、影响范围多大、恢复了没有”。

一条事件通常包含：发生时间、受影响的服务或功能、事件描述（如 API 报错、登录异常）、以及当前处理进度（调查中、已修复等）。历史事件列表可以帮你判断某个服务是偶发问题还是反复出状况。

实用做法：

1. 先看当前状态，确认是否正在故障。
2. 若正在故障，打开对应事件看影响范围和预计恢复信息。
3. 若当前正常，但你想评估可靠性，回看最近的事件频率和持续时间。

三者怎么配合使用

例如你需要连续跑一段自动化任务：先确认状态为正常，再扫一眼最近几天有没有频繁事件，最后看 uptime 是否稳定。三者都过关，才适合把关键任务压在这个服务上。

常见卡点

• 状态正常但你用不了：多半是本地网络、账号权限或区域问题，不是服务宕机。
• uptime 很高却频繁卡顿：降级状态可能不计入“宕机”，但实际体验受影响，要结合事件记录判断。
• 不同窗口数字对不上：确认你比较的是同一时间范围。

AIWatch（ai-watch.dev）是一个 AI 服务实时状态监控平台，用来查看某个 AI 服务当前是否宕机，并追踪其正常运行时间（uptime）与故障事件。它适合在调用某个 AI 服务失败、或准备把关键流程交给某个 AI 服务之前，先确认问题出在服务方还是自己这边。

它解决什么问题

AI 服务出故障时，用户端往往只看到报错、超时或请求失败，很难判断是：

• 服务本身宕机或降级；
• 某个区域、某个模型或某个功能受影响；
• 还是自己的网络、密钥、额度或代码问题。

AIWatch 把多个 AI 服务的运行状态集中到一个页面，让这类判断有一个可核对的参照点。

覆盖范围

根据网站自身描述，AIWatch 监控 46 个 AI 服务，其中明确提到的包括：

也就是说，覆盖对象既有面向普通用户的聊天类服务，也有面向开发者的编程辅助工具。

核心功能

• 实时状态：查看某个 AI 服务当前是否处于宕机状态。
• 正常运行时间追踪：了解服务在一段时间内的可用性表现。
• 故障事件记录：查看发生过的 incident（故障事件），用于回溯某次失败是否与服务方故障时间吻合。

适合谁用

• 开发者：接口报错时先确认上游服务状态，避免把服务方故障误判为自己的代码问题。
• 团队：在依赖多个 AI 服务的流程中，快速定位是哪一个环节的服务出问题。
• 普通用户：某个 AI 工具突然用不了时，判断是普遍故障还是个人环境问题。

使用时的注意点

• 状态页反映的是服务方或监控方的观测结果，不能替代你自己对具体请求的排查；如果状态显示正常但你持续失败，仍需检查密钥、额度、网络与请求参数。
• 监控覆盖 46 个服务，但不代表每个服务的每个模型、每个区域都被单独追踪，判断时以页面实际展示的粒度为准。
• 网站资料未提及收费方式与登录要求，实际使用前以站内当前说明为准。

AIWatch（ai-watch.dev）是一个实时监控 AI 服务运行状态的网站，目前覆盖 46 个 AI 服务，包括 Claude、ChatGPT、Gemini、Cursor、Codex 等。如果你想确认某个 AI 工具当前是否宕机、查看历史在线率和故障记录，可以在该站按服务名称查找对应的状态信息。

覆盖的服务类别与代表服务

根据网站自述，AIWatch 的监控范围集中在主流 AI 产品，可大致归为以下几类：

网站描述中明确点名的只有 Claude、ChatGPT、Gemini、Cursor、Codex 这几个，其余服务名称需要到站内查看完整列表。

如何查找目标 AI 工具的状态

1. 打开 ai-watch.dev。
2. 在服务列表或搜索入口中按名称定位目标工具（如输入 "Claude" 或 "Cursor"）。
3. 进入对应条目后查看当前状态、在线率（uptime）和故障事件（incidents）记录。

预期结果是：能直接看到该服务此刻是正常、降级还是宕机，以及历史上的故障时间线。

覆盖数量与更新方式

网站自述覆盖 46 个 AI 服务，并强调是"实时"监控。但资料中没有说明这份列表的更新频率、新增服务的机制，也没有给出完整的 46 个服务清单。如果需要确认某个具体工具是否已被收录，建议直接在站内搜索该名称；搜不到即说明暂未覆盖。

适用场景

• 你正在用某个 AI 工具，突然无法访问，想判断是自身网络问题还是服务方故障。
• 你想在选型前了解某 AI 服务的稳定性历史。
• 你需要同时关注多个 AI 服务的可用性。

如果你要查的服务不在上述已点名的范围内，先到站内确认是否在 46 个之列，再决定是否以此作为可用性参考。

AIWatch 的核心价值是把 46 个 AI 服务的运行状态聚合到一个页面，适合需要同时关注多个 AI 服务、想快速判断“是不是只有我这边出问题”的用户。如果你只使用一两个 AI 服务，直接看官方状态页通常信息更权威、更新更及时；如果你日常依赖 Claude、ChatGPT、Gemini、Cursor、Codex 等多个服务，AIWatch 的聚合视图能省去逐个打开的步骤。

两者的定位差异

AIWatch 的优势在哪里

一处查看多个服务。 当你同时使用多个 AI 工具，某个服务响应变慢时，第一反应往往是“是我网络问题还是服务挂了”。AIWatch 把多个服务的状态放在同一页面，可以一次性确认是单个服务异常还是普遍性问题。

正常运行时间和故障事件的横向对比。 官方状态页通常只展示自家历史，AIWatch 的聚合形式便于对比不同服务在同一时间段的表现，对评估某个服务的稳定性有参考价值。

覆盖范围包含较新的工具。 从网站描述看，监控对象包括 Claude、ChatGPT、Gemini、Cursor、Codex 等 46 个服务，其中一些开发工具类服务的官方状态页并不总是显眼，聚合站可以降低查找成本。

官方状态页不可替代的地方

信息权威性。 官方状态页是服务方直接发布的信息源，故障定性、影响范围、修复进度的表述以官方为准。第三方聚合站存在同步延迟或判断偏差的可能。

组件级细节。 官方状态页常按组件（如 API、网页端、特定区域）分别标注状态，排查具体功能异常时更精确。

事件沟通渠道。 官方状态页往往附带事件说明和订阅通知，能直接获取服务方的后续更新。

怎么选

• 只用一个 AI 服务：直接收藏该服务的官方状态页即可，AIWatch 的聚合优势用不上。
• 同时依赖三个以上 AI 服务：把 AIWatch 作为日常快速巡检入口，发现异常后再到对应官方状态页确认细节。
• 需要对外说明或正式记录故障：以官方状态页为准，AIWatch 可作为辅助参考。
• 关注某服务长期稳定性：两者结合看，AIWatch 提供横向对比视角，官方页提供纵向历史。

简单说，AIWatch 解决的是“同时看多个服务”的效率问题，官方状态页解决的是“看准一个服务”的准确性问题。两者不是替代关系，按你实际使用的服务数量决定主用哪个。