Thanks for raising this, and apologies for the silence since you filed it.
Being direct: we are not planning a dedicated deprecated-resource report, so I am closing this rather than leaving it in Discovery for another year.
The reasoning. Deprecation warnings already surface in plan output on every run, so detection is not the gap. What is missing is the cross-stack rollup, and demand for that has not been strong enough to compete with what else is in front of us.
In the meantime, a plan policy can flag the resource types or arguments you specify and warn or reject across every stack it is attached to. You maintain the list yourself, which is the real limitation, but it gets you most of the way there.
If this is blocking a provider upgrade or a migration, reply here and I will look again. Upvote count is not the only thing that moves these.
Purple Cookie
•
Jun 14
I think it would be very useful to have it as metadata to the stack, also queryable in the API, possibly also with recording the provider versions.
When managing large setups, it’s sometimes easier to build a dashboard rather than always “look on slack”.
Black Breeze
•
May 10, 2025
Thanks for the suggestion—this is an interesting one. Are you mostly trying to get better visibility into where deprecated resources are being used, or is the goal to block them before they cause issues?
If the warnings are already appearing in the Terraform plan output, one approach today is to surface them through a plan policy. For example, you could write a policy that looks for deprecated resources and flags or blocks the run. That gives you a way to enforce cleanup or notify teams without needing to wait on a product change.
That said, if the pain is more about not knowing which stacks are affected or keeping track over time, we’d love to hear more about where that friction shows up. Understanding that helps us figure out if there’s a better way to support it.
Violet Cake
•
May 10, 2025
Hi Marcin,
Our use case is that we have thousands of stacks and as we upgrade providers want to identify stacks with these warnings so we can fix them. The Infra team doesn’t use all of the stacks and other development teams aren’t particularly incentivized to tell us about these warnings, so we were hoping to have a way to identify the stacks across our system so we could review the warnings and fix them accordingly.
I did look into policies and saw that I could block the run but we don’t want to implement that much friction. If we could make a policy to send a slack message to the Infra team that would be immensely helpful but from the docs I didn’t think that was possible.
Log in to comment and vote
Comments4
Jul 27
PinnedThanks for raising this, and apologies for the silence since you filed it.
Being direct: we are not planning a dedicated deprecated-resource report, so I am closing this rather than leaving it in Discovery for another year.
The reasoning. Deprecation warnings already surface in plan output on every run, so detection is not the gap. What is missing is the cross-stack rollup, and demand for that has not been strong enough to compete with what else is in front of us.
In the meantime, a plan policy can flag the resource types or arguments you specify and warn or reject across every stack it is attached to. You maintain the list yourself, which is the real limitation, but it gets you most of the way there.
If this is blocking a provider upgrade or a migration, reply here and I will look again. Upvote count is not the only thing that moves these.
Purple Cookie
Jun 14
I think it would be very useful to have it as metadata to the stack, also queryable in the API, possibly also with recording the provider versions.
When managing large setups, it’s sometimes easier to build a dashboard rather than always “look on slack”.
Black Breeze
May 10, 2025
Thanks for the suggestion—this is an interesting one. Are you mostly trying to get better visibility into where deprecated resources are being used, or is the goal to block them before they cause issues?
If the warnings are already appearing in the Terraform plan output, one approach today is to surface them through a plan policy. For example, you could write a policy that looks for deprecated resources and flags or blocks the run. That gives you a way to enforce cleanup or notify teams without needing to wait on a product change.
That said, if the pain is more about not knowing which stacks are affected or keeping track over time, we’d love to hear more about where that friction shows up. Understanding that helps us figure out if there’s a better way to support it.
Violet Cake
May 10, 2025
Hi Marcin,
Our use case is that we have thousands of stacks and as we upgrade providers want to identify stacks with these warnings so we can fix them. The Infra team doesn’t use all of the stacks and other development teams aren’t particularly incentivized to tell us about these warnings, so we were hoping to have a way to identify the stacks across our system so we could review the warnings and fix them accordingly.
I did look into policies and saw that I could block the run but we don’t want to implement that much friction. If we could make a policy to send a slack message to the Infra team that would be immensely helpful but from the docs I didn’t think that was possible.
Thanks,
Ben