Challenge 3: What Failed Request Tracing Reveals That a Bare 503
Can't -- Solution Walkthrough

A bare 503 from Rapid-Fail Protection tells you only that the entire
Application Pool was taken offline after crossing the crash
threshold (5 crashes in 5 minutes, by default, per Chapter 2). It
says nothing about what was actually happening inside any one of
those requests right before the worker process crashed -- no module,
no pipeline event, no timing information, nothing that points at an
actual cause. Chapter 2's own recycling settings (periodicRestart,
identity, idle timeout) configure when and how a pool restarts or
recycles -- they don't record or explain why a crash happened in the
first place; they're prevention/mitigation settings, not diagnostic
ones.

Failed Request Tracing fills exactly that gap: for a request that
matches the configured failureDefinitions, it records every pipeline
event and module notification the request passed through, each with
a precise timestamp, up until whatever point the request actually
failed. Applied to a crash-looping pool, this would show the exact
module and exact pipeline event active in the request immediately
before the crash occurred -- turning "the pool went offline" into
"this specific module, at this specific point, on this specific kind
of request, is what's actually crashing the worker process."

An appropriate failureDefinitions configuration to capture this would
target the crash itself rather than a specific status code range,
since a crash may not always produce a clean HTTP status before the
worker process dies -- for example, a broad statusCodes range
covering server errors (500-599) combined with a reasonably short
timeTaken threshold, so that both requests that error out cleanly and
requests that hang right up until the crash get captured, rather than
only ones ending in a specific status code.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can connect Chapter 2's own
crash-loop scenario to this chapter's own Failed Request Tracing
material specifically -- recognizing that recycling/Rapid-Fail
settings are preventive controls, not diagnostic ones, and that
Tracing is what actually supplies the missing "why" Chapter 2 left
unanswered.