One /renew path on a library catalog App Service site returns HTTP 500, and the ordinary HTTP log shows only the status code. Which App Service diagnostic should the developer enable for that failing request?

Ordinary App Service HTTP logs often show only that the library catalog’s /renew path returned status 500, without saying which pipeline stage failed. Failed-request tracing captures detailed request pipeline traces for matching failed requests, giving the developer a focused diagnostic on that one bad path—like a plumber’s camera on a single burst pipe instead of flooding every faucet with permanent verbose logging.

Turning on verbose logging for every success and failure on all routes permanently is noisy, costly on disk or Blob storage, and not the targeted diagnostic the scenario asks for. Replacing App Service with Azure Container Instances just to read docker attach output is unnecessary platform churn; failed-request tracing is an App Service diagnostic capability, not something limited to on-premises Windows Server. Enabling only FTP detailed errors while ignoring request-tracing XML leaves you without the structured failed-request artifacts App Service can produce for HTTP 500 responses.

Exam caveat: failed-request tracing is typically used for targeted investigation and can generate sizable traces—enable thoughtfully, set rules for status codes and paths such as /renew, reproduce, collect the XML, then disable continuous capture if you do not need it running forever.

Operational check: enable failed-request tracing for 500-class responses on /renew, reproduce the failure once, download the trace XML from the site’s diagnostics storage, identify the failing module or middleware step, then turn the capture back down and implement the fix.