Foundry conversations return 404 after ~60 days even though we never deleted them. Is there automatic expiration?

Treat this as an undocumented service-side expiration or defect and open an Azure support request; Foundry Agent Service documentation says conversations persist until explicitly deleted, and no configurable 60-day lifetime is documented for project-endpoint Conversations API resources.^1^

The same exactly-60-day behavior has been reported publicly, but that report has no accepted resolution confirming either an intended retention policy or a customer-side cause.^2^

What the documented behavior says

• Foundry Agent Service is stateful and stores conversations and responses.
• The documented retention behavior is persistence until explicit deletion.^1^
• The Conversations v1 reference defines retrieve, update, delete, and item operations, but specifies no expiration parameter or retention setting.^3^
• The documented 60-day limit applies to stored voice conversations and Microsoft-managed audio, not ordinary project-endpoint text conversations.^4^

A 60-day rule also exists for A2A tasks and contexts, but that is a separate A2A endpoint mechanism and does not establish a limit for /openai/v1/conversations.^5^

Your chronological cutoff, continued success for newer IDs using the same endpoint and credentials, and partial item availability make endpoint, authentication, and knowledge-base configuration poor fits. They do not, however, establish whether the purge is an unintended backend policy or a product defect.

Open a support case with reproducible evidence

Include:

1. Foundry account/project resource IDs, region, subscription ID, and whether the project uses Basic or Standard setup.
2. A few affected conversation IDs and unaffected control IDs—avoid posting additional production IDs publicly.
3. For each ID:
   • Creation timestamp
   • Last-write timestamp
   • First observed 404 timestamp
   • Exact request path and HTTP status
   • Response body
   • apim-request-id response header
4. Results from the same credential and base URL for:
   • GET /openai/v1/conversations/{conversation_id}
   • GET /openai/v1/conversations/{conversation_id}/items
   • GET /openai/v1/conversations/{conversation_id}/items/{item_id}
5. A table showing that failures begin approximately 60 days after creation, including whether later writes reset that interval.
6. A reference to the documented “persists unless explicitly deleted” behavior and the matching Q&A report.

Ask support to confirm whether a backend retention policy is being applied to this project and whether the missing conversation records can be recovered. The public documentation does not expose a setting that can extend or disable such a 60-day expiration.

Production mitigation

Do not use service-side conversation retrieval as the sole durable chat archive while this is unresolved:

• Persist conversation metadata, ordered user/assistant messages, timestamps, and the Foundry conversation/response IDs in your own database.
• Write each user message before invoking Foundry and store the completed assistant response immediately afterward.
• If retrieval returns 404, create a replacement conversation and reconstruct the required context from your durable transcript.
• Retain request IDs and lifecycle timestamps so future losses can be correlated.

The Responses API supports stateful multi-turn operation, but that does not replace application-owned archival storage or establish indefinite retrievability.^6^

References

1. Foundry Agent Service frequently asked questions
2. Conversation resource returns 404 after exactly 60 days
3. Microsoft Foundry REST Reference - Azure OpenAI - Conversations
4. Foundry Agent Service limits, quotas, and regional support
5. Connect to an A2A agent endpoint from Foundry Agent Service (java)
6. Use the Azure OpenAI Responses API - Microsoft Foundry