Change impact analysis

The core idea is simple. Before a change ships, you should know what it will touch. In practice, that is hard to answer accurately when service graphs are large, documentation is stale, and dependencies have formed without anyone keeping a formal record of them.

Our first two versions tried to infer impact from static configuration. It worked for well-documented services and broke down everywhere else. The version shipping in v2 works from the live dependency graph instead. Every analysis reflects the system as it actually exists right now, not as it was documented six months ago.

High-risk paths get flagged automatically. If a change touches a service with degraded health, or one that sits upstream of a large number of consumers, that surfaces before anything ships. Several teams in our beta caught incidents at the analysis stage that would have hit production otherwise.

Onboarding, rebuilt

The old onboarding flow got new workspaces to their first mapped service in around 20 minutes. That was too long. The v2 flow gets you there in under five.

We removed every step that was not strictly necessary for the first mapping. Configuration that used to happen upfront now happens progressively, as you actually need it. The dependency graph starts populating immediately, so you see value before you have finished setting things up.

Everything else

Health monitoring now shows a 30-day incident trend per service alongside the current status. It gives you a faster read on whether a service has been stable or has been quietly degrading over time.

The dependency graph renderer is significantly faster on large graphs. Workspaces with 200 or more services were hitting noticeable lag on initial load. That is gone in v2.

Impact analysis reports are now exportable as a shareable link or PDF. A few teams asked for this specifically for pre-deploy review workflows where not everyone is in STRAND.