Current behaviour When using the Invoke Pipeline activity with Wait on completion enabled, the duration reported for the Invoke Pipeline activity in the parent pipeline's monitoring is significantly longer than the child pipeline's own run duration (as shown in the child pipeline's run history). The gap is invisible orchestration overhead — queueing, connection/token acquisition (the Preview activity relies on a linked service/connection), metadata persistence, status polling, and checkpoint writes between parent and child. In nested patterns this overhead compounds with each level. Why this matters Misleading monitoring: the parent activity looks slow when the child actually finished quickly, making it hard to attribute time and diagnose real performance bottlenecks. Penalises recommended patterns: modular, reusable, parameterised child pipelines (a pattern Microsoft itself promotes) are the worst affected, because every hop adds overhead. Cost transparency: since Fabric CU consumption is duration-based, it is unclear how much of this orchestration wait time is billed versus actual child execution. Customers can't currently see or reason about this. Requested improvement In the activity output and monitoring view, break the Invoke Pipeline activity duration into its components (e.g. queued / orchestration overhead / child execution time) so the actual child run time is clearly distinguishable from orchestration wait. Ideally, also reduce the orchestration overhead of the Preview activity (particularly connection/token acquisition) and confirm that CU billing reflects actual execution rather than idle orchestration time. Repro Create a child pipeline with a single short activity (e.g. a 5-second Wait). Create a parent pipeline with an Invoke Pipeline (Preview) activity calling it, Wait on completion = true. Run the parent and compare the Invoke Pipeline activity duration against the child pipeline's own reported run duration. Observe the parent activity reports a substantially longer duration than the child's actual run.
... View more