From b0bfa43bfaef9aa6c2c7c15d7f66906fa197134d Mon Sep 17 00:00:00 2001
From: Frode Flaten <3436158+fflaten@users.noreply.github.com>
Date: Wed, 1 Jul 2026 19:36:46 +0200
Subject: [PATCH] Update documentation on Run durations in parallel runs

Fixing mismatch in docs vs code. In parallel runs total phase durations at run-level are set to zero
---
 docs/usage/result-object.mdx | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/docs/usage/result-object.mdx b/docs/usage/result-object.mdx
index d47726d..c0dbe83 100644
--- a/docs/usage/result-object.mdx
+++ b/docs/usage/result-object.mdx
@@ -219,15 +219,7 @@ The good news is that **the result object has the exact same shape** as a sequen
 This is the most important difference. Because files overlap in time, summing their durations would overstate how long the run actually took. So in a parallel run:
 
 - **`Run.Duration` is the wall-clock elapsed time** of the whole run (`Now - ExecutedAt`), not the sum of the container durations.
-- **`Run.UserDuration`, `Run.FrameworkDuration` and `Run.DiscoveryDuration` are still the cumulative work** summed across all workers.
-
-As a result, the per-phase totals can **exceed** `Run.Duration` - that is expected, because several files were doing work at the same time. The `Duration = Discovery + User + Framework` identity that holds for a sequential run **does not hold** for a parallel `Run`. Per-container and per-test durations are unaffected: each reflects that worker's own time.
-
-```powershell
-# Parallel: UserDuration can be larger than the wall-clock Duration
-$result.Duration       # e.g. 00:00:04  (wall clock)
-$result.UserDuration   # e.g. 00:00:11  (work across all workers)
-```
+- **`Run.UserDuration`, `Run.FrameworkDuration` and `Run.DiscoveryDuration` are set to zero. Phase durations are still available per container, block and test.
 
 ### Container order is preserved, not finish order