# SC100：服务一直未就绪

> SC100（服务一直未就绪）表示在 readiness.timeoutMs 用完之前，就绪检查路由没有返回预期的状态码。本文列出常见原因和对应的修复方法。

Source: https://shutdown.jscrate.dev/zh/docs/codes/sc100
Last updated: 2026-09-23

`SC100` 表示进程一直存活，但在 `readiness.timeoutMs` 到期前，就绪检查（readiness）路由没有返回预期的状态码。测试请求和关闭信号都还没有发送。

| | |
| --- | --- |
| 诊断码 | `SC100` (FAIL) |
| 阶段 | 启动与进行中的工作 |
| CLI 退出码 | 1 |
| 含义 | 在 `readiness.timeoutMs` 用完之前，就绪检查路由没有返回预期的状态码。 |
| 输出信息 | `Service did not return HTTP <readiness.status> at <url> within <readiness.timeoutMs> ms` |
| 首先检查 | 检查启动命令、`baseUrl` 中的端口、就绪检查的路径和状态码，以及服务的 stderr。 |

## 应该检查什么？

1. 确认 `baseUrl` 的主机和端口与服务一致。
2. 访问 `readiness.path`，看它实际返回的状态码。
3. 确保服务绑定在 `127.0.0.1`、`localhost` 或 `::1` 上。
4. 查看捕获的 stdout 和 stderr 中有没有启动警告。
5. 只有在启动确实很慢时，才调大 `readiness.timeoutMs`。

```json title="shutdown-check.json"
{
  "baseUrl": "http://127.0.0.1:3000",
  "readiness": {
    "path": "/health",
    "status": 200,
    "timeoutMs": 30000
  }
}
```

服务启动期间连接被拒绝是正常的，shutdown-check 会继续轮询。如果进程在等待期间退出，结果会变成 [SC101](https://shutdown.jscrate.dev/zh/docs/codes/sc101)。

## 如何确认已修复？

用同样的命令启动服务，请求完全相同的就绪检查 URL。它必须直接返回配置的状态码，不能要求认证，也不能重定向。

修复后，时间线中会出现 `service ready — HTTP 200`，后面紧跟一个测试请求事件。如果就绪几乎用满了整个超时时间，先排查启动为什么慢，不要只是再次调大上限。

## 相关内容

- [就绪检查配置](https://shutdown.jscrate.dev/zh/docs/configuration#readiness)
- [SC101：服务在就绪前退出](https://shutdown.jscrate.dev/zh/docs/codes/sc101)
- [排查启动问题](https://shutdown.jscrate.dev/zh/docs/troubleshooting)