Microsoft Azure Foundry - 500 Internal server error

Question

Hi!
I have been building an agent on Microsoft Foundry. It has access to an endpoint which it can use to execute SQL queries. The schema is provided in the system prompt. My issue is that sometimes if I ask it in the beginning to look up the DB it runs to 500 internal server error on the Azure side, no tokens spent, no tools used, just plain error message. However, after asking a few questions the DB call seems to work. Is there a way to debug the internal azure error?

Answer 1

Hi Farsang Bence

When an Azure AI Foundry Agent returns HTTP 500 with no tokens spent and no tool invocation, the failure is not coming from your SQL endpoint or from model inference. The error occurs inside the Foundry Agent runtime before execution, during internal initialization or validation, which is why no tool call or token usage is recorded.

This pattern is commonly seen on the first user turn because the agent runtime is still performing cold‑start activities such as agent graph initialization, system‑prompt parsing, and tool/schema preparation. If the very first message forces a database lookup, the runtime may fail before it is fully “warm.” After a few conversational turns, the same DB call often succeeds because the agent state is already initialized. [learn.microsoft.com]

Foundry Agents intentionally return an opaque 500 error for failures that occur during internal tool or agent preparation. At this stage, the service does not surface schema validation details, model reasoning errors, or tool‑dispatch diagnostics. The only usable artifact is the Request ID, which Microsoft can inspect internally. [Cannot acc...rosoft Q&A | Learn.Microsoft.com]

The only supported way to gain visibility is to connect the agent to Application Insights from the Foundry portal. Using the Trace / Monitor tab, you can confirm whether the failure happens during initialization versus execution and capture the Trace ID and timeline. This does not reveal the exact root cause, but it confirms the failure stage. [learn.microsoft.com]

Microsoft‑acknowledged mitigations include: • Sending a cheap warm‑up prompt (non‑tool message) before any DB lookup, to avoid cold‑start failures. • Avoiding tool schemas that are hard to deterministically compile (for example, very generic request bodies or ambiguous structures). • Ensuring the first user message does not force immediate tool selection. These approaches reduce the chance of hitting the initialization failure path.

If the issue is reproducible even after warm‑up, there is no customer‑side fix. You must raise an Azure support request and include the Request ID, UTC timestamp, agent ID, project name, and a minimal reproduction. Only the Foundry product team can inspect these internal 500 errors.

I hope this is helpful!

Thankyou!

Answer 2

Hello Farsang Bence,

Welcome to Microsoft Q&A,

Microsoft Foundry uses Application Insights (OpenTelemetry) for observability and tracing. In the Foundry portal:

1. Go to your Agent/workflow, Trace Tab, and use the Connect button (As highlighted in the image below)
2. You could connect to an existing or new Application Insight for the Agents/workflow
3. Once connected, you can view traces in Foundry (Trace ID, timeline, status, error details).

If you’re using managed agents in the portal:

• Go to the Agent → Monitor tab to see run success rate/latency etc.
• From there, you can jump to Azure Monitor (“View in Azure Monitor”) for the Agents view in Application Insights.

The error pattern is common with transient service startup/warm-up / eventual consistency. Try a cheap warm-up call right after creating/opening the agent session (even a simple non-tool prompt).

Please Upvote and accept the answer if it helps!!