status-quo
收藏资源简介：
status-quo 数据集是一个收集自 10 个 SaaS 提供商（包括 GitHub、Cloudflare、Discord、Reddit、Vercel、Linear、Notion、Netlify、DigitalOcean 和 npm）公共状态页面的原始及 LLM 解释的故障事件数据集。该数据集服务于 status-quo 项目，项目提供公开代码和仪表板（ronniechong.com/status-quo），但数据集本身保持私有，仪表板仅使用预计算的小型 JSON 摘要。数据按提供商和月份分区存储，包含两种类型的 Parquet 文件：一是原始抓取快照，记录每次 API 请求的响应状态、JSON 正文和标准化时间戳；二是 LLM 标记的故障事件，每行对应一个已解决的故障，包含 LLM 生成的标题、摘要、影响面、故障来源、变通方案信息，以及代码计算的指标（如首次更新耗时、更新频率、组件数、严重性等），还包含来源、模型版本等溯源信息。当前未解决的故障记录为轻量行（无 LLM 解释）。此外，还维护一个覆盖元数据 JSON 文件，记录每个提供商的收集开始时间、最后成功抓取时间和收集间隔。数据集的核心约束包括：LLM 生成的标题/摘要不超出事件原文，所有可确定性计算的指标均由代码计算而非模型，严重性直接使用提供商报告的原词。该数据集适用于故障分析、服务可靠性研究、SaaS 状态监控等场景。
The status-quo dataset is a collection of incident event data, including raw and LLM-interpreted information, gathered from the public status pages of 10 SaaS providers (including GitHub, Cloudflare, Discord, Reddit, Vercel, Linear, Notion, Netlify, DigitalOcean, and npm). This dataset serves the status-quo project, which provides public code and a dashboard (ronniechong.com/status-quo), but the dataset itself is kept private; the dashboard only uses precomputed small JSON summaries. The data is partitioned by provider and month and stored in two types of Parquet files: one is raw crawl snapshots, recording the response status, JSON body, and normalized timestamp for each API request; the other is LLM-tagged incident events, where each row corresponds to a resolved incident, containing LLM-generated title, summary, impact, root cause, workaround information, along with code-computed metrics (e.g., time to first update, update frequency, number of components, severity, etc.), as well as provenance information such as source and model version. Currently unresolved incidents are recorded as lightweight rows (without LLM interpretation). Additionally, a coverage metadata JSON file is maintained, recording the collection start time, last successful crawl time, and collection interval for each provider. The core constraints of the dataset include: LLM-generated titles/summaries must not exceed the original event text; all deterministically computable metrics are computed by code rather than the model; severity directly uses the original terms reported by the providers. The dataset is suitable for scenarios such as incident analysis, service reliability research, and SaaS status monitoring.
status-quo 数据集概述
数据集简介
status-quo 数据集收集了10家 SaaS 服务商（GitHub、Cloudflare、Discord、Reddit、Vercel、Linear、Notion、Netlify、DigitalOcean、npm）公开状态页面上的原始事件数据及 LLM 解读数据。这些服务商均使用 Atlassian Statuspage 实例。数据集为 status-quo 项目提供数据支撑，该项目代码公开，仪表板可在 ronniechong.com/status-quo 访问。需要注意的是，该数据集本身保持私有，仪表板仅展示从数据集中派生的小型预计算 JSON 摘要，不会直接公开原始数据。
数据结构
数据分区方式
数据集按服务商和月份进行分区，由定时管道（约每6小时抓取一次，批量导出）追加更新。文件不会被原地重写，每个文件对应一个服务商在一个日历月内的数据。
raw 抓取快照（data/{provider_id}/{YYYY-MM}.parquet）
| 列名 | 类型 | 说明 |
|---|---|---|
| id | string | 快照 ID |
| provider_id | string | 10个服务商 ID 之一 |
| fetched_at_utc | string (ISO) | 快照采集时间 |
| http_status | int | 服务商 API 的响应状态码 |
| body | string | 原始 JSON 响应体（逐字保留） |
| normalized_timestamps | string (JSON) | 从 body 中提取的每个事件的 {raw, utc} 时间戳对 |
LLM 标记的事件数据（interpretations/{provider_id}/{YYYY-MM}.parquet）
每个已解决事件对应一行，以 (incident_id, provider_id, prompt_version) 为键。字段分为三组：
LLM 生成字段（仅包含标题/摘要/分类信息）： title、summary、affected_surface、fault_origin、workaround_offered、workaround
代码计算字段（绝不交给模型处理）： time_to_first_update_min、updates_per_hour、component_count、is_retroactive、severity（服务商原始报告词汇，不做修改）、source_url、created_at、resolved_at、duration_hours（若事件仍未解决，或服务商自身的 created_at/resolved_at 时间差小于60秒或为负值，则返回 null——视为不可靠数据而非发布误导性数字）、incident_status
来源追溯字段（始终存在，永不隐藏）： model_used、prompt_version、schema_version、interpreted_at_utc
当前未解决事件会生成一个轻量级的无 LLM 行（model_used 为 "none"，prompt_version 为 "raw-v1"），每个周期更新，直到事件解决并由真实解读数据替换。
采集元数据（coverage/latest.json）
单个文件，每次导出时完全覆盖。包含每个服务商的采集开始时间、最后一次成功抓取时间以及观察到的采集间隔窗口——为仪表板的"历史深度"和覆盖度指标提供数据支持。
核心原则
- title/summary 中的任何事实不得超出事件自身更新文本所陈述的内容——通过提示约束强制执行，而非仅凭期望。
- 所有可确定性计算的指标（时长、计数、比率）在架构层面均由代码计算，绝不交给模型处理。
- severity 始终使用服务商自己的原始词汇，不做任何修改——不经过模型判断，也不跨服务商进行比较或排名。
