Excluding Traces from Retention Policies in Phoenix Projects

·Jul 10, 2025 06:45 AM

Hi! It's great that Phoenix has retention policies in place now. I was wondering whether it was possible to somehow exclude certain specific traces from a project policy. For instance by being able to move/copy a trace from a project with a short retention to a project with a longer retention? This would be useful in order to retain specific important cases longer.

10 comments

· Sorted by Oldest

RunLLM
APP
·
Phoenix does not support moving or copying traces between projects to change their retention policy. Traces are unique and immutable to a project once ingested; logging the same trace to another project will not duplicate it there. The only workaround is to change the trace or span IDs before ingesting into a different project, effectively creating a new trace instance in the target project with its own retention policy. This is a manual process and not a built-in feature for selective retention or trace migration between projects. See GitHub issue #3645 for details and workarounds.Would you like more detail on how to implement this workaround or manage retention policies per project?Sources: - GitHub issue #3645
💡 Hint: Mention RunLLM in the thread for followups.
Jasper H.
·
Currently I'm actually sending in traces twice into different projects (with updated span-ids), but this brings more complexity in the application logic. So I was looking for a more elegant solution to mark retention per trace.
Roger Y.
·
That sounds like a reasonably use case. You can file an enhancement request here for us to track it
Jasper H.
·
Great! Just to double check: should I focus my feature request to somehow have the ability exclude specific traces from their related retention policy? Or focus already on the proposed solution of being able to copy traces between projects?
Roger Y.
·
i think copying is the easiest, because we currently don’t have any database facility to capture exceptions within the policies
👍1
Mikyo
·
Jasper H. - just a thought but if you have a means to distinguish these traces (either through annotations or metadata) there might be a way for you to pull this data out and either put them in a different project via the client or just store them in cold storage. Just a thought to unblock you.
🙌1
Jasper H.
·
Thanks! There are indeed annotations with which I can distinguish the spans, but I didn't see any way to retrieve the complete trace belonging to a specific annotated span through the API.
Jasper H.
·
https://github.com/Arize-ai/phoenix/issues/8537
1
Roger Y.
·
Thanks fro the PR. I think moving is simplest because otherwise we need to propagate the copy to all the foreign keys
👍1
Mikyo
·
Jasper H. Just shipped transfer trace in the UI. Hope it works for you! Thanks for your feedback

RunLLM
APP
·
Phoenix does not support moving or copying traces between projects to change their retention policy. Traces are unique and immutable to a project once ingested; logging the same trace to another project will not duplicate it there. The only workaround is to change the trace or span IDs before ingesting into a different project, effectively creating a new trace instance in the target project with its own retention policy. This is a manual process and not a built-in feature for selective retention or trace migration between projects. See GitHub issue #3645 for details and workarounds.Would you like more detail on how to implement this workaround or manage retention policies per project?Sources: - GitHub issue #3645
💡 Hint: Mention RunLLM in the thread for followups.
Jasper H.
·
Currently I'm actually sending in traces twice into different projects (with updated span-ids), but this brings more complexity in the application logic. So I was looking for a more elegant solution to mark retention per trace.
Roger Y.
·
That sounds like a reasonably use case. You can file an enhancement request here for us to track it
Jasper H.
·
Great! Just to double check: should I focus my feature request to somehow have the ability exclude specific traces from their related retention policy? Or focus already on the proposed solution of being able to copy traces between projects?
Roger Y.
·
i think copying is the easiest, because we currently don’t have any database facility to capture exceptions within the policies
👍1
Mikyo
·
Jasper H. - just a thought but if you have a means to distinguish these traces (either through annotations or metadata) there might be a way for you to pull this data out and either put them in a different project via the client or just store them in cold storage. Just a thought to unblock you.
🙌1
Jasper H.
·
Thanks! There are indeed annotations with which I can distinguish the spans, but I didn't see any way to retrieve the complete trace belonging to a specific annotated span through the API.
Jasper H.
·
https://github.com/Arize-ai/phoenix/issues/8537
1
Roger Y.
·
Thanks fro the PR. I think moving is simplest because otherwise we need to propagate the copy to all the foreign keys
👍1
Mikyo
·
Jasper H. Just shipped transfer trace in the UI. Hope it works for you! Thanks for your feedback