Choosing a Latency SLO from Measured p90/p95 Performance

PCDOE By islever Editorial Last updated

Balancing change, velocity, and reliability of the service.

Short answer

C Publish 190 ms at p90 and 330 ms at p95, a modest buffer above the measured 160 ms and 300 ms so the SLO preserves error budget without hiding regressions.

Question

You need to define SLOs for a high-traffic web application. Customers are currently happy with the application performance and availability. Based on current measurement, the 90th percentile of latency is 160 ms and the 95th percentile of latency is 300 ms over a 28-day window. What latency SLO should you publish?
  1. 90th percentile - 150 ms 95th percentile - 290 ms
  2. 90th percentile - 160 ms 95th percentile - 300 ms
  3. 90th percentile - 190 ms 95th percentile - 330 ms Correct Answer
  4. 90th percentile - 300 ms 95th percentile - 450 ms

Key Takeaways

It tests the boundary between an SLI baseline and an SLO target, and the main trap is copying today’s 160/300 ms measurements directly into the SLO with no error budget.

This PCDOE question tests how to turn measured p90/p95 latency into a publishable SLO. The correct choice is C, which sets 190 ms p90 and 330 ms p95—modestly looser than the 160/300 ms baseline.

Common mistake: Option B is tempting because it matches the current 160/300 ms measurements, but an SLO equal to current performance leaves no error budget and turns normal variance into perceived breaches.

Expert Analysis

The boundary: baseline measurement versus SLO target The current 90th-percentile latency of 160 ms and 95th-percentile latency of 300 ms are observed measurements over a 28-day window. They are inputs to SLO design, not automatically the published SLO. An SLO is a target plus a compliance window and an error budget; if the target is exactly today’s percentile, ordinary variance can consume the budget immediately and make the service appear non-compliant while customers are still satisfied.

Why C is on the SLO side of that boundary Option C publishes 190 ms at p90 and 330 ms at p95, a modest relaxation above the measured baseline. It stays anchored to real customer experience while creating headroom for traffic spikes, deployments, and measurement noise. Option A is tighter than current performance and risks unnecessary breaches. Option D is so much looser than current performance that it weakens accountability and could hide real regressions. The close call is between B and C.

What the comments clarify Some readers defend B because the measured values match current satisfaction, but the comments also point out that “B does not provide any error budget at all,” while another states that “SLO should never be the same as current performance.” The measurement is evidence for choosing a target; the published SLO needs a little slack. Therefore C is the correct latency SLO.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When an SLO question gives current measurements and says users are satisfied, classify each option against the baseline: tighter than current is risky, equal to current leaves no budget, and far looser hides regressions. Pick the modest buffer above the measured p90/p95 values unless the stem explicitly says to enforce current performance as an SLA. This same baseline-versus-target filter transfers to availability and error-budget questions.

Frequently Asked Questions

Why is Option B not the right latency SLO if it matches current performance?

An SLO equal to the current p90/p95 values leaves no meaningful error budget. Normal variance can consume the target immediately, causing false breaches even while users remain satisfied; C gives a small, deliberate buffer.

How much headroom should a latency SLO have over measured performance?

There is no universal number; the practice is modest, not huge. Here 190 ms p90 and 330 ms p95 keep the SLO close to the 160/300 ms baseline while allowing for normal variance; D is too relaxed.

What does the 28-day window represent in this SLO decision?

It is the measurement and compliance window. The observed percentiles over 28 days describe current behavior, while the published SLO uses that baseline plus error budget for the same window.

More PCDOE FAQ →

Community Votes

C
63%
B
37%

63% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 9 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 9

  1. cachopo 👍 2 Answered B
    The appropriate latency SLO to publish would be 90th percentile - 160 ms and 95th percentile - 300 ms, as these values reflect the current performance measurements over a 28-day window. These values are based on the actual data, and since customers are already happy with the application's performance and availability, it's reasonable to set the SLOs in line with the current performance metrics.
  2. ricardovazz 👍 2 Answered B
    In B SLO makes sense because it pushes engineering teams to maintain strong performance. Then, a more relaxed SLA could be introduced to reduce financial risk, and so that consumers don´t assume current performance as the SLA.
  3. Mileke 👍 2 Answered C
    SLO should never be the same as current performance. You should always leave some room for error budget.
  4. LONGBOW_RA 👍 2 Answered C
    When setting up SLO based on SLI, there should be some margin, but not too much. Therefore C
  5. 8136dd0 👍 2 Answered C
    C because you should set SLOs with some space between the current performance
Show 4 more comments
  1. khush6 👍 1 Answered B
    B. 90th percentile - 160 ms, 95th percentile - 300 ms Why? SLOs Should Reflect Current User Happiness: Since customers are already satisfied with the current performance (90th @ 160ms, 95th @ 300ms), these values should be your baseline SLOs. Tightening the SLO (e.g., Option A) risks unnecessary breaches, while loosening it (e.g., Options C/D) reduces accountability. Google SRE Best Practices: SLOs should be based on historical data (here, 28-day measurements). Avoid overpromising (A) or undercommitting (C/D). Percentile Choice: The 90th/95th percentiles are standard for latency SLOs (captures "most users" without outliers dominating). Why Not the Others? A (Tighter SLOs): Unnecessary risk—why promise 150ms if users are happy with 160ms? C/D (Looser SLOs): Degrades trust—customers expect consistency, not regression.
  2. maurer 👍 1
    C. Setting SLOs with reasonable headroom (190ms/330ms) above current performance (160ms/300ms) follows SRE best practices by providing operational flexibility while maintaining customer satisfaction.
  3. BlackCoffee 👍 1 Answered C
    Customer are happy. SLO should never be the same as current performance. You should always leave some room for error budget.
  4. bartrek 👍 1 Answered C
    C since B does not provide any error budget at all and D seem too relaxed

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Mitigating Downstream Service Failures with Circuit Breakers

S-grade

Error Budget Exhausted: Should You Deploy an Urgent Customer Feature?

S-grade

SRE Postmortem Triggers: External Stakeholders and Data Loss

S-grade

Centralizing Production Folder Logs with an Aggregated Log Sink

S-grade

Practice All PCDOE Questions

Access 75 questions with complete answers and detailed explanations.

View Full PCDOE Practice Test →

← Back to PCDOE Study Guide