Hosted Agent (Foundry) container fails to start (ActivationFailed/Waiting) and all invoke/session calls return 500

Hello @Rajender Akula ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

The observed behavior—where the agent continuously cycles through Waiting > Activating > Unhealthy > ActivationFailed and all invoke or session calls return HTTP 500 across multiple configurations—strongly indicates that the failure is occurring during the managed container activation phase, rather than within application logic.

Container activation and startup logs for hosted agents are not exposed through the Foundry portal or APIs.

This means there is no direct visibility into:

• Container startup or crash logs
• Image pull or registry authentication events
• Orchestrator scheduling or node-level activation processes
• Internal health probe execution during initialization

Only high-level lifecycle states (such as Waiting, Activating, ActivationFailed) and API response indicators (such as HTTP 500) are externally available.

As of now, some limited telemetry is available

1. Application Insights / Azure Monitor tracing captures execution telemetry such as latency, exceptions, and request flow once the agent is running
2. Activity Logs provide resource-level provisioning and deployment signals
3. Diagnostic settings if enabled may emit operational telemetry

However, these signals are post-start in nature and do not capture early-stage container activation or startup failures. If the agent fails before reaching a healthy state, these tools typically do not provide root-cause-level diagnostic information.

To confirm whether the issue is environmental, configuration-related, or platform-level, the following checks are recommended:

1. . Review agent version error details
   1. Please retrieve agent version status via API or SDK
   2. Inspect error.code and error.message fields for indicators such as:
   • image pull failures
   • authentication issues
     • configuration validation errors
2. Please validate container startup independently
3. Run the same container image in a local or standard container hosting environment
   1. This can be confirmed when:
      • container starts successfully
      • application endpoints (e.g., /responses) respond immediately
      • no blocking initialization logic exists
4. Verifying startup behavior and dependencies
5. Avoid long-running initialization during container boot
6. Ensure required environment variables and secrets are correctly configured
   1. Confirm there is no dependency on unavailable external services during startup
7. Please validate registry and identity access
8. Confirm container image accessibility and correct tagging
   1. Validate permissions for private registry access if applicable
   2. Ensure configuration alignment across resources
9. Confirm consistency across tests The following pattern is significant:
   • multiple agent versions tested
   • different model deployments validated
   • rebuilt images deployed
   • identical failure behavior observed
   This consistency strongly reduces the likelihood of an application issue and points toward a platform-level activation failure.

If continued progress is required during investigation,then please try to see if the following helps

1. Deploy the container in a standard hosting environment and invoke model endpoints directly
2. Use a minimal test container to validate baseline startup behavior
3. Evaluate non-hosted execution patterns where direct model endpoints are used

The following references might be helpful , please check them out

• Hosted agents in Foundry Agent Service (preview) - Microsoft Foundry | Microsoft Learn
• Deploy a hosted agent - Microsoft Foundry | Microsoft Learn
• Set Up Tracing for AI Agents in Microsoft Foundry - Microsoft Foundry | Microsoft Learn

Thank you

Hi Rajeswari,

Thanks for your response.

We have already validated most customer-side checks: protocol is set to responses / 1.0.0, port is 8088, multiple fresh images were rebuilt and pushed, multiple agent versions were tested, a different model deployment was tested, and required environment variables were also injected explicitly. The failure pattern remains the same in every case: versions cycle through Waiting, Activating, Unhealthy, and ActivationFailed, and direct version-specific invoke/session calls return HTTP 500.

Based on that, this appears increasingly likely to be a managed hosted-agent activation failure rather than normal app logic or model configuration. If anyone has seen this exact pattern and found a customer-side fix, please share what external check exposed it. We can also provide exact UTC timestamps and correlation/request IDs privately if a Microsoft moderator or product engineer can inspect backend traces.