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.

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