Affected scope
project: foundry-deploy
Problem to solve
Foundry Deploy currently tracks deployment session telemetry through deploy:session_finished, including overall duration, success state, cancellation state, completed step count, failed step name, and deployment context. It does not include timing details for individual deployment steps.
Without per-step timing in the session event, it is harder to understand which parts of the deployment workflow are slow or unreliable while keeping telemetry volume low.
Proposed solution
Add compact per-step timing data to the existing deploy:session_finished event.
The telemetry should include:
- Step duration values in seconds for each deployment step.
- Step status values for each deployment step: succeeded, failed, skipped, or cancelled.
- The existing session-level context already captured today.
The implementation must not emit additional telemetry events. In particular, it should not add a deploy:step_finished event.
The data should remain low-cardinality and sanitized. It must not include sensitive values such as computer names, full paths, URLs with query strings, credentials, tokens, Wi-Fi secrets, SSIDs, or user-provided sensitive values.
Alternatives considered
Adding a separate telemetry event per deployment step would make step analysis straightforward, but it would increase telemetry event volume and make usage volume harder to interpret. Keeping everything inside deploy:session_finished preserves one telemetry event per deployment session while still exposing step-level performance data.
Use case
A maintainer wants to understand which deployment stages are slow or unreliable without increasing the number of telemetry events emitted by Foundry Deploy. Step timing in deploy:session_finished makes it possible to analyze deployment bottlenecks while preserving clean session-level usage volume.
Checklist
Affected scope
project: foundry-deploy
Problem to solve
Foundry Deploy currently tracks deployment session telemetry through
deploy:session_finished, including overall duration, success state, cancellation state, completed step count, failed step name, and deployment context. It does not include timing details for individual deployment steps.Without per-step timing in the session event, it is harder to understand which parts of the deployment workflow are slow or unreliable while keeping telemetry volume low.
Proposed solution
Add compact per-step timing data to the existing
deploy:session_finishedevent.The telemetry should include:
The implementation must not emit additional telemetry events. In particular, it should not add a
deploy:step_finishedevent.The data should remain low-cardinality and sanitized. It must not include sensitive values such as computer names, full paths, URLs with query strings, credentials, tokens, Wi-Fi secrets, SSIDs, or user-provided sensitive values.
Alternatives considered
Adding a separate telemetry event per deployment step would make step analysis straightforward, but it would increase telemetry event volume and make usage volume harder to interpret. Keeping everything inside
deploy:session_finishedpreserves one telemetry event per deployment session while still exposing step-level performance data.Use case
A maintainer wants to understand which deployment stages are slow or unreliable without increasing the number of telemetry events emitted by Foundry Deploy. Step timing in
deploy:session_finishedmakes it possible to analyze deployment bottlenecks while preserving clean session-level usage volume.Checklist