# SC111: Work was never in flight

> SC111 (work was never in flight) means the workload finished, or never showed it started, before SIGTERM. Use a slow streaming endpoint or a probe barrier.

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

`SC111` means shutdown-check could not prove that the workload was active. It
does not send `SIGTERM` in this state because a completed request cannot test
graceful draining.

| | |
| --- | --- |
| Code | `SC111` (FAIL) |
| Stage | Startup and in-flight work |
| CLI exit code | 1 |
| What it means | The workload finished, or never showed that it had started, before the signal could be sent, so nothing was in flight to drain. |
| Messages | `Every work request must remain active after response headers; use a slow streaming test endpoint or a probe barrier with one request`<br>`Work completed before its start probe became active`<br>`Work-start probe did not become HTTP <activeStatus> while work remained active` |
| First thing to check | Use an endpoint that stays open while it works, or a `probe` start barrier that reports the operation has begun. |

## Which barrier are you using?

With `response-headers`, every request must receive headers while its body is
still open. Flush the headers early and finish the body later:

```js
response.writeHead(200, { "content-type": "text/plain" });
response.flushHeaders();
setTimeout(() => response.end("work complete\n"), 2000);
```

With `probe`, the separate route must change from `inactiveStatus` to
`activeStatus` before the workload response finishes.

## How do I fix it?

1. Choose the barrier that matches how the handler responds.
2. Make the test workload last longer than startup and signal delivery.
3. Raise `started.timeoutMs` only if the work really takes longer to begin.
4. For concurrent requests, use `response-headers`; a probe supports one.

A fast health route is not a useful workload. Use a controlled slow endpoint
that represents real work without changing production data.

## How do I verify the fix?

Look for this order in the timeline:

```text
work request sent
work confirmed active
signal sent
```

If `work request finished` appears before `work confirmed active`, the route is
still too fast or the barrier is observing the wrong state.

## Related

- [Test in-flight work](https://shutdown.jscrate.dev/docs/in-flight-work)
- [Start-barrier configuration](https://shutdown.jscrate.dev/docs/configuration#start-barrier)
- [SC110: Probe already active](https://shutdown.jscrate.dev/docs/codes/sc110)
- [SC112: Work ended before SIGTERM](https://shutdown.jscrate.dev/docs/codes/sc112)