What should happen when an orchestrator terminates an ASP.NET Core container that is serving requests and running background work?

Graceful container shutdown for .NET services

Handles SIGTERM, traffic draining, cancellation, background work, and termination deadlines without losing accepted work or hanging rollout.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

ASP.NET Core's host responds to the shutdown signal and exposes cancellation to hosted services. I mark the instance unready, let in-flight requests drain within a configured timeout, and pass stopping tokens through queue waits, database calls, and HTTP calls. Background workers stop claiming new jobs first. A job that cannot finish safely should preserve a checkpoint or return to a durable queue rather than blocking shutdown indefinitely.

Full answer below

Practice focus

SIGTERM, host shutdown, readiness, cancellation tokens, request draining, background workers, deadlines, and idempotent recovery.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The orchestrator normally sends a termination signal and allows a grace period before force-killing the process. The service should stop accepting new work, cancel or finish bounded work, and exit within that deadline.
ASP.NET Core's host responds to the shutdown signal and exposes cancellation to hosted services. I mark the instance unready, let in-flight requests drain within a configured timeout, and pass stopping tokens through queue waits, database calls, and HTTP calls. Background workers stop claiming new jobs first. A job that cannot finish safely should preserve a checkpoint or return to a durable queue rather than blocking shutdown indefinitely.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The container entrypoint must allow the application process to receive signals; shell wrappers need exec behavior or explicit forwarding. The orchestrator's grace period must exceed the application's drain budget plus a small margin. Long requests need product-level decisions such as asynchronous jobs or resumable work because no shutdown timeout can guarantee arbitrary completion. Cleanup remains bounded and should not start new remote work while termination is underway.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Ignoring the host stopping token.
Continuing to claim queue messages during shutdown.
Running through a shell that swallows termination signals.
Assuming every request can finish before termination.

What should happen when an orchestrator terminates an ASP.NET Core container that is serving requests and running background work?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement