A blood-bank courier App Service site fails only while a tester is clicking through a multi-step form. The developer needs to watch application output during that live repro. Which approach fits best?

When a failure happens only during a live multi-step form repro, the developer needs a real-time tail of application output—not a workbook built after the tester has gone home. App Service log stream in the portal, or az webapp log tail from the CLI, follows that live stream while the blood-bank courier tester clicks through the form. That interactive path matches the scenario: watch application output during the repro itself.

Authoring a Log Analytics workbook with custom Kusto joins before reproducing the click path delays the investigation and is the wrong first tool for watching live stdout. Disabling all logging and relying solely on HTTP 500 counts in an Azure Advisor scorecard provides no application detail and no timeline tied to the tester’s steps. Waiting for the next nightly blob roll of filesystem logs means the repro window is closed and the transient state that caused the failure may already be gone.

Exam caveat: application logging must already be enabled for meaningful stream content to appear. Log stream is for interactive troubleshooting; durable Blob application logs and Application Insights remain better for historical analysis, alerting, and sharing evidence after the live session ends.

Operational check: enable application logging, open log stream or run az webapp log tail against the web app, reproduce the multi-step form failure with the tester, and capture the stdout or ILogger lines that coincide with the error before closing the stream. Archive a snippet into the incident notes.