Skip to content
Clairos Learn

Cost, capacity, and reliability · Lesson 11 of 14 · 9 min

Read reliability targets

Reliability targets need a measure and window. Keep user-visible success separate from process uptime so an alive but unusable system is not counted as healthy.

Open the labCourse map
Mastery 0/3Run itExplain itApply it
learner@clairosSimulated AI Ops lab
learner@clairos:~ $
↑ history · Tab complete · Ctrl+C cancel · Esc, Tab to leaveExit 0

Understand the pattern

Reliability targets need a measure and window. Keep user-visible success separate from process uptime so an alive but unusable system is not counted as healthy.

Interpret the evidence

Investigate the 97 percent request success rate despite high process uptime.

A tempting mistake

High process uptime guarantees the request-success target was met.

All names, measurements, prices, versions, and thresholds in this exercise are fictional training data. The evidence supports this bounded scenario, not a claim about a live provider.

Worked example and expected result
$ cat /opt/ai-lab/cases/aiops-cost-reliability-011.json
{
  "fixture": "Fictional training data; not a live measurement.",
  "process_uptime": 0.9999,
  "successful_requests": 0.97,
  "success_target": 0.99
}

Exit status: 0. The command completed successfully in the training fixture.

$ jq .successful_requests /opt/ai-lab/cases/aiops-cost-reliability-011.json
0.97

Exit status: 0. The command completed successfully in the training fixture.

$ printf '%s\n' 'investigate-request-success' > /home/learner/lab/aiops-cost-reliability-011-decision.txt
(no output; exit 0)

Exit status: 0. The command completed successfully in the training fixture.

Try a variation

Name the assumption that would have to change for “investigate-request-success” to stop being the justified action. Do not silently replace missing evidence with a guess.

Explain it

What does the evidence in “Read reliability targets” justify?

Apply it elsewhere

A colleague concludes: “High process uptime guarantees the request-success target was met.” What should you do?

Keep the momentum.

Complete the lab, then explain and apply the pattern.

Next: Prepare a capacity noteTry an incident drill

Anonymous lesson and mastery progress lasts for this session. Sign in to keep synced lesson XP between sessions; mastery stays device-local. No speed bonus, lost lives, or hint penalties.

Keep learning

  1. 01Plan graceful degradationGraceful degradation retains a safe useful subset when dependencies fail. Make the reduced behavior explicit rather than pretending the full service is healthy.Practice
  2. 02Prepare a capacity noteA capacity note records observed demand, tested limits, bottlenecks and the next safe experiment. Include uncertainty rather than promising unmeasured scale.Practice
  3. 03Review cost anomaliesCost anomalies require separating request volume, token length, model selection and retries. Compare those drivers before treating an invoice increase as a provider error.Practice

Case methodology: evidence, limits, decision