# SC000: Graceful shutdown verified

> SC000 (graceful shutdown verified) is the pass result: what shutdown-check proved about your service, what it does not cover, and how to keep it in CI.

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

`SC000` means the configured graceful shutdown behavior passed. The active
requests finished, the process exited correctly before the deadline, and the
port stopped accepting connections.

| | |
| --- | --- |
| Code | `SC000` (PASS) |
| Stage | Passed |
| CLI exit code | 0 |
| What it means | Every in-flight request finished with the expected response, and the service exited with the expected code before the deadline and closed its port. |
| Message | `Graceful shutdown verified` |
| First thing to check | Nothing to fix. Keep the check in CI so a regression fails the build. |

## What did the test prove?

The service passed every check enabled in your config:

1. The test port was free before startup.
2. The service started and became ready.
3. The workload was active before `SIGTERM`.
4. Each active request returned the expected status and body.
5. The process exited with the expected code before the deadline.
6. The port closed after the process exited.

If you enabled readiness withdrawal, rejection of new requests, or a repeated
signal, those checks passed too.

## What did it not prove?

The result covers only the routes and conditions in the config. It does not
verify database writes, queue consumers, WebSockets, HTTP/2 streams, or work
that continues after an HTTP response. It also does not test Kubernetes
endpoint propagation or a container `preStop` hook.

Use a workload that represents a real slow operation, and keep the test in CI
so shutdown regressions fail before deployment.

## How do I keep the result meaningful?

Review the config when routes, startup commands, or platform deadlines change.
A test can keep passing while no longer representing production if the
workload becomes much faster or the deployed entry point changes.

In CI, keep the full timeline or JUnit report. A normal passing sequence shows
work active before `SIGTERM`, response completion after it, and process exit
before `shutdown verified`.

## Related

- [Understand each stage](https://shutdown.jscrate.dev/docs/how-it-works)
- [Choose a realistic workload](https://shutdown.jscrate.dev/docs/in-flight-work)
- [Run the test in CI](https://shutdown.jscrate.dev/docs/ci)
- [Compatibility and limits](https://shutdown.jscrate.dev/docs/compatibility)