In my green-SLO case, the system had a clean 200 ms SLO while users still waited 2–3 seconds. The path responsible for the stall lived outside what the tools measured.
The next useful question is precise: what does this measurement include?
A workflow measurement contract gives that question a written answer. It names the action, the completion signal, the conditions and the person who will act on the evidence. The contract below is a proposed tool to adapt to your system.
Define what completion means
Consider an illustrative Save workflow. Start the proposed timer when the application records the user activating Save. Stop when the defined confirmation is visible and the user can continue.
Write down what that confirmation promises. Does it mean the operation was accepted, the intended change was saved, or the next action is ready? Choose the signal that matches the workflow's actual promise.
A request timer ending when a response arrives would describe a smaller boundary if work remains before that completion signal. Map the remaining work and decide how to observe it. This is an example of boundary design, not a report of a completed test.
Keep the definition specific enough that another engineer can implement it and recognize when it fails to capture the experience you intended.
Copy this workflow measurement contract
Leave unknowns visible. Fill the contract before interpreting a latency result.
- Boundary: [workflow and user population; recorded start event; end event; included and excluded work]
- Completion signal: [observable event and recording method; what it confirms; how to identify a missing or ambiguous completion]
- Workload, data and cache: [operation mix; arrivals or concurrency; dataset size and shape; cache state and procedure; version and environment]
- Target and summary: [completion-time threshold and desired proportion; rationale; eligible-attempt denominator; observation window; optional percentile and sample count]
- Failures and timeouts: [failed, incomplete, cancelled and timed-out attempts; deadline; how each outcome is counted and reported]
- Hidden work: [work before or after existing component timers; conditions that trigger it; remaining observation gaps]
- Resource countermetric: [relevant resource, such as CPU, memory or queue depth; agreed limit; observation window]
- Decision owner: [person responsible; review point; next action when the target is missed or the evidence is inconclusive]
Latency among completed attempts is one part of the record. Keep failures and missing completions visible beside it. Otherwise, you may interpret a changing population as an improving workflow.
Use the contract to make a decision
Choose the target from the workflow's needs and available evidence. For a completion-time objective, count which eligible attempts completed successfully within the target. State the denominator and window; eligible failures remain in that denominator. Add a percentile view of completed attempts when useful, with its population and sample count.
Use the prediction record to state what a proposed change should improve and what would challenge that explanation. Use the data-growth comparison guide when the workload changes behind an unchanged request rate.
Review the contract when complaints fall outside its boundary, completion semantics change, or the tested population no longer represents the workflow. Record the revision so earlier and later measurements remain interpretable.
The owner should be able to explain what was measured, what remains unknown and which action the evidence supports.
Source posts: Responsiveness · Workflow SLOs · Hidden latency case.
Further reading: Google SRE's Implementing SLOs separates the user outcome to assess from the method used to measure it, and explains objectives using proportions of good events.