Engine 19.0.0rc597 · Reader 9.0.0rc656 · Development snapshot
What does lead time measure?
Lead time measures the elapsed time from an object's first recorded observation to its closure. A ticket first observed on Friday and closed on Monday includes the intervening night and weekend. The clock continues when nobody records work.
Ghost Observatory publishes this duration as objects.lead_time_sec. An individual closed object can have outcome completed, cancelled or merged. The completed-object summaries use a narrower population, described below.
L = tclose − tfirst
A worked example with parallel steps
Consider a complete event history with a declared order. The final activity is configured to close the object.
| Activity | Start | End | Processing time |
|---|---|---|---|
| A | 09:00 | 09:10 | 10 minutes |
| B | 09:02 | 09:08 | 6 minutes |
| Close | 09:12 | 09:14 | 2 minutes |
The lead time is 840 seconds, or 14 minutes. Its processing-time total is 1,080 seconds because the overlapping durations add to 18 minutes. The whole-object waiting total is withheld because one transition overlaps.
Lead time therefore answers how long the object existed in the observed process. Processing time and waiting time describe different parts of the recorded evidence.
Which start and closure does the Engine use?
For an event history, the start is the earliest recorded observation, including an earlier annotation row. It is generally different from a creation date held elsewhere in the source system. A separate object-master record without process events can supply a declared creation instant, but does not create a missing event history.
A supported closing activity, an admissible resolved object record or a declared merge can establish closure. The closing instant must agree with the object's observed chronology. A status label alone cannot supply a duration when its timestamp is unknown.
Reopening can extend the object's final lifetime. Lead time measures the envelope through final closure; it does not subtract a previously closed interval. The time-weighted WIP calculation handles those intervals separately.
When is the value missing?
An open object has no observed final lead time. The Engine also withholds it when a required start is unknown, ordering or lifecycle evidence is inadequate, closing evidence conflicts, or the proposed closure precedes a later recorded event.
An object partly outside a bounded analysis window has its whole-life duration withheld in that window. Select the unbounded scope to examine its complete admitted history. A missing value does not mean the object took zero seconds.
Summaries and the Reader
The Reader's object detail displays the published object fields. Lead-time rows in duration_stats have duration_source = lead_time and summarize completed top-level objects. A median needs five known lead times; P90 needs twenty. Counts can include completed objects whose lead time is unknown, so inspect the population before interpreting a blank quantile.
The estimated median time to close answers another question: it includes eligible objects that remain open through right censoring, and treats cancellation and merging as closure. A completed-only median cannot stand in for that estimate.
Lead time versus processing time and cycle time
Lead time covers an elapsed start-to-finish interval, including recorded gaps. Processing time describes activity durations inside that history. Parallel activity means that adding processing durations can exceed elapsed lead time, as the example above shows.
Teams also use the term cycle time, but its start and end boundaries vary. Before comparing a cycle-time report with this measure, identify the actual start event, closing event, clock and eligible objects. Renaming a column does not make two differently bounded durations comparable.