Engine 19.0.0rc597 · Reader 9.0.0rc656 · Development snapshot
What counts as waiting?
Waiting time measures gaps between process steps. Ghost Observatory calculates those gaps from recorded process steps, after allowing earlier parallel steps to finish and subtracting admitted linked activity. A gap shows an absence of recorded activity on that clock. It cannot establish that nobody was doing anything.
An individual transition stores object_transitions.wait_sec. An object's total_wait_time_sec adds its measurable transition gaps and the durations of activities explicitly configured as external waiting.
gi = si − max(ej, for earlier steps j)
wi = gi − ci
Why the immediately preceding finish is insufficient
Suppose a declared event order is A, B, C. Their intervals, expressed as seconds from the start, are A: 0–10, B: 2–4 and C: 12–14.
| Step | Latest earlier finish | Published wait | Overlap |
|---|---|---|---|
| A | No predecessor | NULL | NULL |
| B | 10 | NULL | Yes |
| C | 10 | 2 seconds | No |
C's gap is 12 − 10 = 2 seconds. Subtracting B's finish would give eight seconds and incorrectly count time while A was still running. B has an overlap, so its waiting time is unknown rather than a negative value. The overlapping transition also prevents publication of a complete object waiting total.
Associated work and external activities
The Engine can subtract running intervals on other objects when admitted links establish that the activity belongs to this object's gap. It merges those covering intervals before subtraction, so simultaneous linked intervals cover the clock once. Unusable or ambiguous links do not establish associated activity.
Activities named in EXTERNAL_WAIT_ACTIVITY_TOKENS contribute their own duration to total_wait_time_sec. The separate external_activity_time_sec also includes the measured gap after each external activity, up to the next step: the object is treated as remaining with the outside party until then.
Consequently, total waiting is not lead time minus processing time. The three fields use different evidence and admission rules.
Transition summaries and targets
An activity edge summarizes occurrences of the same directed step pair within an object type. transition_count counts occurrences; object_count counts distinct objects. A looping object can contribute more than once.
The activity-edge median requires five known waits and P95 requires forty. Both are withheld if any transition on that edge overlaps or has an unknown wait. The Reader's slow-transition list selects published waits at or above the published P95.
A person-to-person handover edge has a different rule: its median uses only known waits and publishes known_wait_count beside it. Person edges have no P95 waiting statistic.
WAIT_TARGET_SECONDS supplies a configured target for the destination activity. A transition exceeds it only when wait_sec > wait_target_sec. Equality meets the target; an unset target remains empty.
When the clock cannot support a wait
A wait is withheld for unknown prior finishes, unusable clock or order evidence, overlapping steps, or a projected arrow that skips a canonical event. An arrow belonging to a linked object has no inherited wait: the Engine measures this clock along the events' own object.
The object's waiting total additionally requires complete history and decided order. It is withheld for a window fragment or an unknown required gap. Read these missing values with the underlying events and diagnostics before describing a transition as a queue or bottleneck.