Why is fire-and-forget work risky in a .NET web application?

Fire-and-forget task risks in .NET

Explain why starting background work without awaiting or tracking it is risky in ASP.NET Core applications.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Fire-and-forget means starting asynchronous work and not awaiting or tracking it. In a web API this is risky because exceptions may be lost, the request scope may end, and the application may shut down before the work finishes. It can also use scoped services like DbContext after they have been disposed. I prefer a proper background queue or hosted service when the work must happen reliably.

Full answer below

Practice focus

Task lifetime, exception handling, scoped services, request boundaries, shutdown behavior, and reliable background processing.

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
Untracked asynchronous work has no clear owner for exceptions, service lifetimes, retries, or shutdown. In a web process that can turn a small convenience into lost business work or code running after its request scope has been disposed.
Fire-and-forget means starting asynchronous work and not awaiting or tracking it. In a web API this is risky because exceptions may be lost, the request scope may end, and the application may shut down before the work finishes. It can also use scoped services like DbContext after they have been disposed. I prefer a proper background queue or hosted service when the work must happen reliably.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, sending an email after an order is created should not usually be _= SendEmailAsync() inside the controller. If email matters, I would write an outbox record or enqueue a background job and let a worker process it with retries and logging. The trade-off is complexity: for non-critical telemetry or best-effort cache warming, fire-and-forget may be acceptable, but I still want explicit error handling and shutdown behavior.

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

Starting a task and ignoring its exception.
Using DbContext or scoped services after the request ends.
Treating important business work as best effort.
Forgetting app shutdown and deployment behavior.
Adding fire-and-forget to hide slow request latency instead of designing a reliable async workflow.

Why is fire-and-forget work risky in a .NET web application?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement