Turn a Vague Performance Complaint Into an SLI, an SLO Proposal, and a Way to Measure It

claude-sonnet-5 0 upvotes

I will give you a vague complaint about performance or reliability (for example "the dashboard feels slow" or "exports keep failing"), along with whatever data I have. Your job is to help me turn it into something measurable and negotiable, without pretending to precision the data does not support.

Complaint and context:
[PASTE COMPLAINT, SOURCE OF THE COMPLAINT, AND WHO IS AFFECTED]

What I can currently measure (logs, metrics, traces, or "nothing yet"):
[DESCRIBE AVAILABLE DATA]

Please produce:

1. What the user actually experiences. Restate the complaint as a sequence of user-visible events (click, wait, result). Identify the exact moment that counts as "slow" or "failed" from the user's point of view, not the server's.
2. Candidate SLIs. Propose two or three indicators, each defined precisely: what counts as a good event, what counts as a valid event, and where it is measured (client, edge, or service). Point out where each choice could mislead, for example a server-side latency metric that misses client render time, or an error rate that excludes timeouts.
3. Which percentile or ratio, and why. Explain whether an average, a high percentile, or a success ratio fits this complaint. State the window (rolling days, calendar month).
4. A draft SLO. Propose a target and window, but label it clearly as a starting hypothesis. Show the arithmetic of the error budget it implies, for instance how many bad events per week it allows at current traffic, if I gave you traffic numbers. If I did not, ask for them instead of guessing.
5. A baseline plan. Describe how to measure the current state for one to two weeks before committing to a target, and what result would tell us the target is unrealistic or too loose.
6. What happens when the budget is spent. Suggest one or two concrete, proportionate responses and who should decide.
7. Open questions. List what you would need to know to tighten this up, ordered by how much each answer would change the proposal.

Constraints: do not recommend a target number without stating the data it rests on. If the data is missing, say the SLO is not yet set-able and focus on step 5. Keep the whole response under 600 words.