Skip to main content

Show delta details on hover in the stack list

Feature RequestsUI/UXDrift DetectionResources

In the stack list, each stack shows an aggregate delta badge (~2, +3 −12, or a collapsed "2 deltas"). Today the only way to see which resources changed is to click into the stack and then navigate back. A tooltip or hover popover showing the resource-level breakdown — resource addresses plus change type — would let us triage a list of unconfirmed drift in place. Expanding the collapsed "N deltas" badge on hover would help for the same reason.

Workaround
Problem
Status: ⬆️ Gathering votes1 comment

Log in to comment and vote

Comments1

  • Natalia Gazda

    Team•

    Sep 25

    Hey @Julien Covington thanks for the request!

    So first on what’s already possible.

    1. Triage from the account-level Resources view instead of the stack list. That view is cross-stack and vendor-agnostic, with search and filtering, and it surfaces drift and lifecycle context per resource. Instead of walking the stack list and clicking into each drifted stack, you can work from the resource inventory directly - you see resource addresses and change context in one place, filter down, and deep-link to a specific resource. Would that work for you?

    2. Push the "does this matter?" decision into a notification policy so it comes to you pre-triaged. Drift detection runs are flagged in policy input, and notification policies can filter, route, and rewrite messages, including building rich summaries of resource changes. A lot of teams find routine drift triage works better as a push ("here are the drifted resources matching rules we care about, with addresses and change types, in Slack or the inbox") than as a manual pull through the UI. This targets exactly the thing you flagged - that the friction discourages routine triage - by removing the manual review pass for the common cases and letting you reserve the click-in for the genuinely ambiguous ones. If you need support I’m happy to let our support team know, and they could reach out to help you craft the policy :)

    3. Save a "drifted" view so the list itself stays put. You mentioned losing your place on every round trip. Stacks can be filtered by state (including unconfirmed and drifted) and saved as a named, shareable view. It doesn't remove the click-in, but it means you return to a stable, filtered list every time rather than re-scrolling and re-filtering. Combined with (1) or (2), it keeps the manual round-trips to the genuinely ambiguous handful.

    I would recommend starting with option 2 and seeing if that solves your problem.

    One more questions that I would have is when you look into a stack, is it more often about the “does it matter” or the need to actually see the diff?

    For now, I’m opening it up to gathering votes, to see if there’s more demand :)

  • Linked to Stack list to link directly to unconfirmed run details