SC111: Work was never in flight

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 Work completed before its start probe became active 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:

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?

Choose the barrier that matches how the handler responds.
Make the test workload last longer than startup and signal delivery.
Raise started.timeoutMs only if the work really takes longer to begin.
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:

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.

SC111: Work was never in flight

Which barrier are you using?

How do I fix it?

How do I verify the fix?

Related