status.afterpack.dev 显示每个公开的 AfterPack 服务是否正常运行,以及最近 90 天里每一天的可用比例。该页面只读取一个端点,你也可以读取它:用于监控脚本、仪表盘,或者在 Pro 构建之前等待故障结束的 CI 步骤。
端点
GET https://api.afterpack.dev/v1/status
无需密钥、会话或请求体。任何来源都可以在浏览器中调用它。响应可能被缓存 60 秒(Cache-Control: public, max-age=60),因此每分钟轮询超过一次不会得到新数据。
curl https://api.afterpack.dev/v1/status服务如何被检查
监控程序每 5 分钟从 Cloudflare 的网络检查一次每个服务:
| 服务 | 主机 | 视为正常的条件 |
|---|---|---|
| API | api.afterpack.dev | 健康检查返回 200 且包含 "status":"ok"。 |
| 网站 | www.afterpack.dev | 首页返回 200。 |
服务在连续 2 次检查失败后变为 down,并在第一次检查通过时恢复为 up。每一次检查都计入当天的可用率,包括没有使服务变为 down 的单次失败。
响应
{
"status": "operational", // overall, see below
"checkedAt": "2026-10-20T09:15:02Z", // latest check of any service
"intervalSeconds": 300, // time between two checks of a service
"services": [
{
"id": "api",
"name": "API",
"host": "api.afterpack.dev",
"status": "up", // up | down | unknown
"since": "2026-10-18T22:40:01Z", // when status last changed
"uptime": 99.982, // percent over the 90 days
"days": [
{ "date": "2026-07-23", "checks": 288, "uptime": 100 },
// ... one entry per UTC day, oldest first, today last
{ "date": "2026-10-20", "checks": 112, "uptime": 99.107 }
]
}
]
}| 字段 | 含义 |
|---|---|
status | 所有服务正常时为 operational,部分服务故障时为 partial_outage,全部故障时为 major_outage,首次检查之前为 unknown。 |
checkedAt | 最近一次检查的时间,首次检查之前为 null。若该值远早于 intervalSeconds,说明监控程序本身已停止。 |
services[].id | 服务的稳定标识。 |
services[].status | up、down,尚未检查的服务为 unknown。 |
services[].since | 服务最近一次变为正常或故障的时间,首次检查之前为 null。 |
services[].uptime | 90 天内通过检查所占的百分比,没有检查时为 null。 |
services[].days | 恰好 90 条,每个 UTC 日一条。没有检查的日子 uptime 为 null。 |
可用率向下取整到三位小数,因此有一次检查失败的日子显示为 99.652,绝不会显示 100。此响应可能新增字段;已有字段的含义保持不变,与整个 Cloud API 的规则一致。
API 无法访问时
该端点由 API 本身提供,因此当 api.afterpack.dev 无法响应时,/v1/status 也无法响应。此时状态页面会读取 Cloudflare 的状态,并说明 Cloudflare 是否报告了自身的问题。在脚本中也应同样处理 /v1/status 请求失败:视为 API 故障。
下一步
- SLA、SLO 与支持:这些检查所衡量的可用性目标。
- Cloud API 参考:API 的其余部分及其版本规则。
- 构建与 CI:API 故障期间 Pro 构建会怎样。