Machines are the wrong thing to measure
Bad objectives measure machines. Processor above 80 percent, memory pressure, queue depth.
See what is wrong with all three. None of them is a promise to a user, and every one of them pages somebody for conditions users never notice.
Sit your objectives at the user boundary and describe outcomes. Checkout requests succeed. Search returns within 400 milliseconds. The uploaded photo is visible within 5 seconds.
Test each one by trying to finish the sentence the user experienced. If you cannot, it is an internal metric wearing an objective's badge.
Use percentiles for anything about latency, because averages are a hiding place. An average of 90 milliseconds coexists perfectly happily with a slowest percentile of 4 seconds, meaning one customer in a hundred has a miserable time on every single request.
Target the tail you actually care about, as a ratio: requests under 400 milliseconds, and set the ratio from what your traffic really does.
Where targets come from
Derive your targets from measurement rather than ambition. Measure where you are now, find where users actually complain, and set the target slightly tighter than the complaint line, usually near what you already achieve.
Avoid the aspirational number. Five nines on a system delivering 99.7 produces a permanently exhausted budget and a team trained to ignore it. Each added nine roughly multiplies your cost in redundancy, automation and on-call weight, so every one needs a business justification rather than a vanity one.
Watch the other direction too, because overperforming has its own cost. Users calibrate to what you deliver, not to what you promised.
Learn from the internal lock service that became so reliable that teams across the company built as though it could never fail. Its owners began deliberately taking it down to its stated objective, flushing out the hidden dependencies while the failures were still cheap.
Keep the portfolio small, two to four objectives per service. Twenty targets means none of them can drive a decision, and driving decisions, what gets built next, what wakes somebody up, when launches pause, is the entire point.
Worked example
Yuki inherits an on-call rotation averaging 40 pages a week for a five-person team, built from about 200 threshold alerts accumulated over six years: processor, disk, heap, queue depth, all of it. She runs a two-week audit and finds that 34 of the last 40 pages required no action at all, while an 11-minute checkout outage in the same period never paged anyone, because no alert watched checkout. The rewrite goes SLO-first: three targets, checkout availability at 99.95, search under 400 ms at p99, the number the slowest one request in a hundred comes in under, for 99 percent of requests, order webhook delivery within 60 seconds at 99.9. Paging moves to burn-rate alerts on those three; the 200 old alerts become dashboard panels. Pages drop to about 5 a week, and the next checkout regression pages in 4 minutes because now something is actually watching what users feel.