Define a user-visible success indicator

TL;DR: Define success from the user's operation and keep eligible events explicit, so a healthy process cannot hide a failing booking journey.

Where you are. Start the reliability course with the measurement contract. You will use this definition to decide when an incident begins and when it ends.

Pick the operation before the metric

Parcel accepts bookings and later assigns couriers. A successful booking acknowledgement and a timely courier assignment are different user outcomes. Combining them into one vague uptime number makes failures difficult to interpret. Define an indicator for each important operation, with the observation point and eligibility rule recorded.

For the exercise, an eligible event is a syntactically valid booking request received at the service boundary, including capacity rejections. A good event returns a correct acknowledgement within 800 milliseconds. State how you treat client cancellation, duplicate retries, validation errors and requests rejected before admission. Excluding every failed request by definition would make the indicator meaningless.

Keep correctness and latency visible

A 200 response with the wrong booking identifier is not a good event. A correct response delivered after the deadline can still violate the latency objective. A synthetic probe may verify a narrow path, while real request telemetry captures a broader mix; neither automatically replaces the other.

Google SRE's SLO implementation guidance discusses selecting user-relevant indicators. The booking rules and threshold here are exercise assumptions, not a universal objective.

Watch for a disappearing denominator

If instrumentation drops failing requests, the indicator can improve while users experience more errors. Compare ingress counts, application counts and rejected telemetry where possible. A route change that moves traffic outside a metric filter can create the same illusion.

Document the query and the service boundary with the SLI. If a release changes status-code behavior, revisit whether the query still measures the intended outcome. During an interview, explain why a health endpoint alone cannot prove this booking objective: it may never execute the booking write or validate the returned identifier.

The goal is a definition another engineer can implement and challenge. A precise but narrow indicator is more useful than a broad percentage whose exclusions nobody can explain.

Explain what the example percentage leaves out

In the exercise's 1,000 requests, 40 fail the eligibility rule, leaving 960 eligible. Of these, 900 satisfy both correctness and the 800-millisecond deadline. The good fraction is 900/960 = 93.75 percent. The 40 slow correct responses and 20 incorrect acknowledgements are different failure types, but both consume this combined objective's allowance.

Keep separate diagnostic counts for those failure types. A latency repair will not fix incorrect booking identifiers. If one request is both slow and incorrect, count that request once in the combined bad-event total, even though both diagnostic counters can increment. Adding the diagnostic counters would otherwise double-count overlapping failures.

Now suppose a new proxy rejects 100 valid requests before they reach the application. Under the stated service-boundary definition, those capacity rejections still belong in the denominator. An application-only counter would omit them and could make the result look better. Collect the rejected events at the boundary or explicitly document the resulting measurement gap.

A request-based indicator also counts retries as requests under this fixture's rule. An operation-based indicator would need stable operation identity and a rule for combining attempts into one user outcome. Choose the measure deliberately; changing from one to the other alters the denominator and breaks an unqualified before-and-after comparison.

Do this before moving on

Classify 1,000 requests: 900 correct and fast, 40 correct but slow, 20 incorrect acknowledgements and 40 invalid requests rejected before admission. Calculate the good-event fraction under the stated fixture.

Expected: 900/960 = 93.75 percent. Keep the 40 excluded requests visible separately. Then explain how a denominator change could falsely improve the result. Pass when you classify both correctness and latency failures and state the exclusion rule before calculating.

Go deeper

• Error-budget arithmetic turns this indicator into an operating decision.
• Symptom alerting connects user impact to actionable pages.
• Cardinality discipline helps retain useful dimensions without unbounded labels.

Key takeaways

• Define eligibility before computing success.
• Correctness and latency both belong to the user contract.
• Audit missing and excluded events alongside the percentage.

Check yourself

Say it before you reveal it. Pulling the answer out of your own head is what fixes it. Nodding along to someone else's does nothing.

1. 1A fast 200 with the wrong booking ID is:

   Good because status is 200Bad under the fixture contractAlways excluded

2. 2Why compare ingress and application counts?

   Answer it, then reveal