Can this feature ship after today's incident?
Northstar Tickets wants to release a checkout feature. Today's incident has ended its main error spike, and the product owner asks to resume.
The question
Fictional exercise. You own the release recommendation. The written policy below governs this request-based SLI.
| Count | |
|---|---|
| All eligible customer attempts in the full window | 10000000 |
| Failed attempts outside today's incident | 7000 |
| Failed attempts in today's incident | 4000 |
The two failure groups do not overlap. Both are included in the full-window denominator. One valid checkout attempt is counted once; a success completes within two seconds. Internal retries and test traffic are excluded.
The target is 99.9% successful eligible attempts in the fixed 28-day window. When failures exceed the allowed count, feature releases stop. Incident restoration and security fixes may proceed under their own review. Feature work resumes only after the window is within target and the incident owner confirms recovery checks. A future release must define its monitoring window, failure threshold and tested restore target.
“Calculate the remaining budget and recommend whether this feature release can proceed.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Define the measured population
What would you do here? Open the move you’d make.
Use only the requests from today's incident
Tempting, but it misses something. That changes the stated 28-day population and policy.
Use the full eligible-request window
The strong move. The policy applies to all eligible attempts in the fixed window.
Convert each failed request to one minute of outage
Tempting, but it misses something. Request failures and time unavailable are different measures.
See how a strong candidate says it
“I would use the ten million eligible attempts in the stated window and the same two-second success rule for both failure groups. This is a request-based SLI. I would not convert its error count into minutes of downtime.”
Why it works: A budget calculation needs a consistent denominator and success definition.
Step 2: Calculate the budget
What would you do here? Open the move you’d make.
Report 110% consumed and 1,000 over
The strong move. 11,000 / 10,000 = 1.1. The negative remaining amount is not free capacity.
Report 70% consumed
Tempting, but it misses something. That omits today's four thousand failures.
Report 99.9% consumed
Tempting, but it misses something. The success target is not the percentage of budget used.
See how a strong candidate says it
“At 99.9%, the allowed failure fraction is 0.1%. Ten million multiplied by 0.001 allows 10,000 failures. Observed failures are 7,000 plus 4,000, or 11,000. That is 110% consumed, with 1,000 failures over budget; observed success is 99.89%.”
Why it works: The two disjoint error groups must both count.
Step 3: Apply the actual release policy
What would you do here? Open the move you’d make.
Ship because the change is small
Tempting, but it misses something. Change size does not override this service's written policy.
Freeze all incident restoration too
Tempting, but it misses something. The policy explicitly allows that work under its own review.
Hold the feature and keep the permitted repairs separate
The strong move. This applies the stated threshold and exceptions without adding a new one.
See how a strong candidate says it
“I would hold this feature release. The policy permits separate incident restoration and security fixes; it does not permit a feature because its code looks small or because the latest chart is improving.”
Why it works: The exception must match the purpose of the proposed change.
Step 4: Name the next release conditions
What would you do here? Open the move you’d make.
Promise the budget will reset tomorrow
Tempting, but it misses something. The packet does not give the age of each error or support that date.
State the policy conditions and owner
The strong move. The decision can be revisited when the required evidence exists.
Restart the 28-day window now
Tempting, but it misses something. Resetting the measurement would hide customer failures.
See how a strong candidate says it
“I would name the release owner and require a window within target, completed recovery checks, a tested restore target and a defined observation window and failure threshold. I would not set an invented date for when old errors leave the window.”
Why it works: A useful hold decision includes observable conditions to resume.
The answer, in short
- Decision
- Hold the feature release under Northstar's written policy.
- Because
- 11,000 observed failures exceed the 10,000 allowed count.
- What would change it
- A compliant window plus completed recovery checks and the required release controls can support a later feature release.
Common traps
- Changing the denominator after an incident.
- Treating a release hold as a ban on incident restoration.
Check your answer
- Did you define eligible attempts and the window?
- Did both failure groups count exactly once?
- Did you calculate 110% consumption and the 1,000 excess?
- Did you state real resume conditions instead of an invented date?
Last reviewed Nov 10, 2026