检测机制

多方交叉验证，得出一个结论

针对每个服务，我们最多采集四个维度的独立信号。其中任意一个都可以触发预警，并以仍然有效的最新信号中最严重的一个决定最终展示的状态。一旦某个数据源中断或失效，我们会直接剔除，绝不采信过期数据。

我们主动发起的探测请求

在具备 API 访问权限的平台上，我们的机器人每隔一到两分钟就会直接向厂商的官方 API 发送一条极短的流式提示词，并记录返回首个 token 所需的时间。探测若失败，会间隔二十秒连续重试两次，全部失败才记为异常。因限流（Rate Limit）返回的响应或我们自身的配置错误均会被直接忽略，避免将健康的服务误判为故障。

• 服务中断 最近连续三次检测均失败
• 部分中断 最近十分钟内有一半及以上的检测失败
• 响应缓慢或异常 最近五次检测中至少有一次失败，或者首字响应时间超过 3 秒且达到过去一天中位数的 3 倍以上

厂商官方状态页

我们每分钟抓取一次官方状态页，且只关注与该服务直接相关的组件——例如针对 ChatGPT，仅监测 ChatGPT 相关组件，而非 OpenAI 旗下的所有业务。如果官方状态页超过十五分钟未更新，我们将直接忽略：冻结或停更的状态页不应让服务强行保持全绿或全红。

来自 OpenRouter 的真实流量

OpenRouter 会公开各供应商旗下每个模型的请求成功率。我们专门监测厂商通过官方 endpoint 提供的模型。当某个厂商至少两个模型且占其模型总数一半以上，在 30 分钟内成功率跌破 80% 且比当天平均水平低 10 个百分点时，该服务会被标记为“响应缓慢或异常”；若平均成功率跌破 50%，则标记为“部分中断”。

如果三个或更多厂商在同一时刻指标同时下跌，问题大概率出在 OpenRouter 自身，届时该信号将被全体忽略。

用户实时反馈

每个服务页面均设有“我遇到了问题”按钮。若 15 分钟内收到 10 起及以上反馈，且反馈频率达到该服务平日的 4 倍，状态将变为“响应缓慢或异常”。单纯的用户反馈绝不会将服务判定为“服务中断”；同一访客针对同一服务每半小时仅计入一次，且每小时设有上限。

严控误报与状态抖动

系统每 30 秒重新计算一次判定结果。若要恢复为“正常”，服务必须连续保持完全正常满三分钟，以防 API 在健康与故障之间反复波动导致页面状态频繁抖动。

如何看懂彩色状态条

24 小时状态条包含 48 个色块，每个代表半小时；30 天状态条每天一个色块。色块颜色取自该时段内记录到的最差状态。灰色代表该时段暂无数据，并不意味着一切正常。

我们的监测盲区

我们的探测节点位于欧洲的数据中心，因此仅限特定国家、特定移动网络或特定局域网的故障可能无法被我们探测到。我们无法获取你个人账户的限额或账单状态。此外，像 Midjourney 这类既无公开 API 又无状态页面的服务，只能完全依赖用户的反馈报告。

数据来源

isAIlive 是 llmlive.ai 的姊妹项目，监控探测由后者实际运行，两站共享相同的数据源。本站只专注于一件事：告诉你当前所需的服务是否正常可用。

llmlive.ai →

状态说明

• 正常 所有监控源均未发现异常。
• 维护中 官方公布了计划内的维护工作。
• 响应缓慢或异常 出现报错或响应变慢，但绝大多数请求仍能成功处理。
• 部分中断 大量请求失败，或某项核心功能不可用。
• 服务中断 绝大多数用户无法正常使用该服务。
• 暂无数据 所有监控源均无最新数据。