An Azure service that enables users to identify content that is potentially offensive, risky, or otherwise undesirable. Previously known as Azure Content Moderator.
Hello Vu Thanh Trung,
Greetings! Thanks for raising this question in Q&A forum.
This is a very detailed and well-structured question! The short answer is there is no built-in in-portal view that shows blocked prompt text with block reasons out of the box. You need to enable Diagnostic Settings first, and then query the logs via Log Analytics. Let me walk you through everything step by step.
Step 1 — Enable Diagnostic Settings (this is mandatory first)
Blocked prompts are NOT logged automatically. You must turn on diagnostic logging before any data starts flowing.
- Go to the Azure Portal and open your Azure OpenAI resource in Japan region.
- In the left menu, click on "Diagnostic settings" under Monitoring.
- Click "Add diagnostic setting."
- Select the log category "RequestResponse" (this captures prompt content and filter results) and also "AuditLogs" if available.
- Choose "Send to Log Analytics workspace" as the destination and select or create a workspace.
- Save the settings. Note that logs will only start collecting from this point forward — past blocked prompts are not retrievable.
Step 2 — Query Blocked Prompts in Log Analytics
Once logs start flowing (usually within a few minutes), do the following:
- Open your Log Analytics workspace and click on "Logs."
- Use the table AzureDiagnostics to query content filter events. Run a query like this to find blocked requests:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where statusCode_d == 400
| where requestPayload_s contains "content_filter"
| project TimeGenerated, requestPayload_s, responsePayload_s
The responsePayload_s field will contain the content_filter_result object which shows the triggered category (hate, sexual, self-harm, violence, jailbreak) and the severity level (safe, low, medium, high).
For custom blocklist matches, look inside the content_filter_result for the custom_blocklists field — it will include the blocklist ID that matched the prompt.
Step 3 — Understanding What Gets Logged
The actual prompt text is captured in requestPayload_s — but be aware this field may be truncated for very long prompts. The filter category and severity are reliably captured in responsePayload_s.
Blocklist-triggered blocks will show a filtered: true flag along with the matching blocklist ID, but the specific term that matched is generally not exposed in logs for privacy/security reasons.
Step 4 — Region and Plan Requirements
- This diagnostic logging approach works in the Japan region and does not require Defender for Cloud or any separate plan standard Log Analytics is sufficient.
However, if you need abuse monitoring with richer insights and human review capabilities, that is a separate feature available under Microsoft's abuse monitoring program and may require specific tier eligibility. For most content filter logging needs, the diagnostic settings approach above is fully supported.
As a best practice going forward, also consider capturing the content_filter_result directly in your application code from the API response this gives you real-time visibility into every blocked request without depending solely on log queries.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix.