如何用Node.js区分Claude Microsoft 365连接器与其他故障事件

用Node.js只读对照三个事故

下面命令适用于macOS或Linux终端中的Node.js 24环境，不依赖额外npm包。三个ID均来自官方事件记录，代码并行读取公开JSON，拒绝重定向，并在返回ID不符时停止；不会访问用户邮箱或Claude账户。

node --input-type=module <<'JS'
const ids = ['sqn3fg1l96dl', 'nn11wk485zfn', '34wq7gxnxvvm'];
const rows = await Promise.all(ids.map(async (id) => {
  const url = `https://status.claude.com/api/v2/incidents/${id}.json`;
  const response = await fetch(url, {redirect: 'error', signal: AbortSignal.timeout(30000)});
  if (!response.ok) throw new Error(`HTTP ${response.status} for incident ${id}`);
  const payload = await response.json();
  const incident = payload.incident ?? payload;
  if (incident.id !== id) throw new Error('Unexpected incident ID');
  const latest = incident.incident_updates.reduce((a, b) =>
    new Date(a.created_at) > new Date(b.created_at) ? a : b);
  return {id: incident.id, name: incident.name, status: incident.status,
    incident_created_utc: incident.created_at, latest_message_utc: latest.created_at};
}));
for (const row of rows) console.log(JSON.stringify(row));
JS

预期输出三条JSON，每条包含事故ID、名称、该事故状态、事件创建时间及最新消息创建时间。读取失败时应检查HTTP或网络错误，不应把缺失响应补成“正常”。这些字段用于核对事件，不是某个具体工具任务的执行结果。

为什么不能只凭同名错误就合并

sqn3fg1l96dl专门记录Microsoft 365连接器事件。其更新明确提到邮件、日历、搜索和Claude for Outlook，并将原因指向Microsoft 365服务事件。此前恢复迹象阶段还明确提及部分SharePoint搜索继续报错。

另外两起事故分别记录Claude登录和多入口服务错误，各自拥有独立ID与时间线。不能把连接器事件已确认的上游原因，自动套到另一场事故；也不能因为另一场事故已解决，就据此认定M365连接器当时也已恢复。

同一个resolved也要保留各自时间线

这次连接器记录后续在UTC时间11月13日21:49:44发布解决说明，并给出实际影响区间。此前15:40的消息仍属于出现恢复迹象、持续监控的阶段。读取最新状态时，也应保留旧消息当时所表达的限制，不能把过去改写成已经完全正常。

解决说明还提到微软仍在完成恢复，可能存在偶发错误或延迟。这是该条说明的限制，不是把所有Claude产品永久归为故障，也不是对所有租户和任务同时成功的保证。

代码中的创建时间为什么不叫故障起点

incident_created_utc表示公开事件对象的创建时间，latest_message_utc表示最新消息的发布时间。实际影响区间可能在后续说明中另行补充，不能把对象创建时间自动当成真实故障起点。

同样，读取发生的当前时间也不是公告时间。这份代码直接打印官方字段，避免拿本地执行时钟替换来源中的原始时间；时间字段相近或服务名相同，都不是合并事故的充分条件。

事件核对后仍需什么业务依据

明确事故身份可以帮助判断错误背景，却不能代替邮件或日历任务自身的返回与实际记录。对结果未知的写入操作，不应仅凭一次状态查询就无条件重发。模型生成了自然语言解释，也不等于工具已经取得有效数据或完成业务动作。