Ever shipped something that looked perfectly healthy on the dashboard – average response time a comfortable 200ms – only to watch support tickets pile up from users who were quietly rage-quitting? That’s the average lying to you. And it lies more often than you’d think.
Here’s the setup that should keep you up at night. Two services. Both report a mean latency of exactly 200ms. One of them has a P95 of 250ms. The other has a P95 of 1.8 seconds. On an averages-only dashboard, these two systems are indistinguishable twins. In reality, one is fine and the other is torching 1 in every 20 requests with a nearly two-second wait. Your monitoring says “all green.” Your users say something less printable.
This is the whole reason percentiles exist, and P95 latency is the metric that turns the lights on.
TL;DR: P95 latency (also written as “95th percentile response time”) is the response time under which 95% of your requests complete. The slowest 5% take longer. It’s the single best window into what your unluckiest users actually experience – and it’s invisible to averages.
This guide is the complete playbook. We’ll cover what P95 really means in plain English, how to calculate it three different ways (including the one mistake that silently corrupts most calculations), how to choose between P95 and P99 for your SLOs, why microservices make tail latency worse, how to optimize P95 by root cause, and – critically – how to prove your P95 target holds under realistic load before you sign an SLA you can’t keep. Business readers get the revenue-and-retention translation; engineers get copy-paste calculations and pass/fail gates. Let’s get into it.
- Why Averages Lie: The Outlier Problem Percentiles Solve
- What Does P95 Latency Actually Mean? (In Plain English and in Precise Terms)
- How to Calculate P95 Latency: Three Methods (and the One Mistake That Ruins Them All)
- P95 vs P99 vs P50: Choosing the Right Percentile for Your SLO
- Tail Latency Amplification: Why Microservices Make P95 Worse
- What Slow Responses Cost You: Translating P95 Into Revenue and Retention
- Optimizing P95 Latency: A Layered, Root-Cause Playbook
- Validating Your P95 SLO With Load Testing (Before an SLA Breach Costs You)
- P95 by Architecture: Monoliths, Microservices, Serverless, and Edge
- Frequently Asked Questions About P95 Latency
- References
Why Averages Lie: The Outlier Problem Percentiles Solve
Most performance articles assert that “averages can be misleading.” Fine. But let’s prove it with actual numbers, because the arithmetic is where the betrayal becomes obvious.
The mean is a summary statistic that assumes your data behaves. Latency data does not behave. It’s dominated by a small number of catastrophically slow requests, and the mean smears those across everything else until they vanish. The Google SRE Book makes this point with a striking, quantified example: a system where a typical request is served in about 50 ms, yet 5% of requests are 20 times slower – roughly a full second. As the book notes, “Monitoring and alerting based only on the average latency would show no change in behavior over the course of the day, when there are in fact significant changes in the tail latency.” [1] Your average stays flat while a growing slice of your traffic suffers.
That’s the outlier problem. A percentile doesn’t average the pain away; it ranks it and reports the threshold. P95 says: “Find the value that 95% of requests beat.” Suddenly the second-slow-second tail is a headline number instead of a rounding error.
Two Systems, One Average, Wildly Different Reality
Let’s make the identical-average scenario concrete. Here are 20 response times (ms) from each of two services.
System A: 180, 190, 195, 200, 200, 205, 210, 190, 185, 205, 200, 195, 210, 200, 215, 190, 205, 200, 195, 210
System B: 90, 95, 100, 85, 90, 95, 100, 90, 85, 95, 100, 90, 95, 100, 85, 90, 95, 1750, 1800, 1900
Both average out to roughly 200ms. Compute the mean and you’d sign off on either one.
Now sort and take the P95. With N=20, the 95th-percentile index is 0.95 × 20 = 19, so P95 is the 19th value in the ascending sort.
- System A: sorted, the 19th value is 210ms. Mean ~200ms, P95 210ms. Boringly consistent.
- System B: sorted, values 18 – 20 are 1750, 1800, 1900. The 19th value is 1800ms. Mean ~200ms, P95 1800ms, P99 pushing toward 1900ms.
Same average. One system’s worst-common experience is 210ms; the other’s is 1.8 seconds. The mean physically cannot tell them apart. The percentile calls it out instantly.
Why Latency Is Long-Tailed, Not a Bell Curve
If latency followed a normal (bell curve) distribution, the mean would sit right in the middle and averages would be trustworthy. It doesn’t. Response times are right-skewed with a long tail, because the things that make requests slow are occasional and violent rather than uniform. As the Google SRE Book puts it, most metrics are “better thought of as distributions rather than averages.” [1]
Three concrete tail-makers you’ll meet in production:
- Garbage-collection pauses: a stop-the-world GC on a JVM or .NET runtime can freeze all in-flight requests for tens or hundreds of milliseconds – rare, but brutal when it hits.
- Serverless cold starts: a function that answers in 40ms when warm can take 1+ second when a new container spins up under a concurrency spike.
- Connection-pool exhaustion: when every pooled DB connection is busy, new requests queue. Most requests are fast; the unlucky few that arrive during saturation wait for a slot, landing squarely in the tail.
Each of these affects a minority of requests and drags them far to the right. The bulk of your traffic stays fast, the mean barely moves, and the tail quietly grows. That’s why you measure distributions, not averages, and understanding the performance metrics that matter helps you decide which of those distributions to track.
What Does P95 Latency Actually Mean? (In Plain English and in Precise Terms)
Definition: P95 latency is the response time value below which 95% of requests complete. If your P95 is 300ms, then 95 out of every 100 requests finished in 300ms or less, and the slowest 5 took longer. “95th percentile response time” is the exact same thing – it’s just the formal label you’ll see in report columns, while “P95” is the engineer’s shorthand.
The Coffee Shop Analogy: Your Worst Common Experience
Picture a coffee shop that serves 100 customers in a morning rush. Ninety-five of them get their order within 3 minutes. The other five – stuck behind a complicated 12-drink office order – wait 10 minutes. The P95 is 10 minutes: it’s the experience of your unluckiest 5%. Not the freak one-off (that’s the max), but bad enough to notice and common enough to matter.
That’s exactly what P95 latency captures for your system: your worst common experience. Precisely: the response time that 95% of requests beat.
Requests vs. Users: The Misconception That Trips Everyone Up
Here’s the trap. P95 is computed over requests, not distinct users. This matters enormously in modern apps. Consider a single-page dashboard that fires 30 API calls on load. If your per-request tail is 5%, then on average roughly 1.5 of those 30 calls (0.05 × 30) land in your slow tail – per page load. One user experiences the tail multiple times in a single interaction. The Google SRE Book’s request-based framing is the correct one to reason from: [1] your P95 describes request outcomes, and a heavy-fan-out page means a user’s odds of hitting the tail compound quickly. “95% of requests are fine” does not mean “95% of users are fine.”
P95 vs. Maximum Latency: Why ‘Max’ Is a Trap
Why not just alert on the slowest request? Because max is noise. A single client timing out at 30 seconds because someone’s laptop went to sleep mid-request will set your max to 30,000ms. Alert on max and you’d page an on-call engineer for a phenomenon that affected exactly one non-representative request out of a million. P95 is stable – it takes a genuine shift in a meaningful fraction of traffic to move it – which is precisely why it’s the industry-standard SLO metric and max is not.
How to Calculate P95 Latency: Three Methods (and the One Mistake That Ruins Them All)
Different roles compute P95 differently. Here are the three paths that matter, then the anti-pattern that quietly poisons all of them.
Method 1: From Raw Samples (The Manual Way)
When you have raw per-request timings, the manual method is dead simple: sort ascending, then take the value at the 0.95 × N index.
Take this 20-sample dataset (ms): 120, 95, 340, 110, 88, 200, 130, 410, 105, 92, 150, 175, 98, 220, 118, 102, 380, 140, 115, 99.
Sorted ascending: 88, 92, 95, 98, 99, 102, 105, 110, 115, 118, 120, 130, 140, 150, 175, 200, 220, 340, 380, 410.
Index = 0.95 × 20 = 19. The 19th value is 380ms. That’s your P95. (For non-integer indices, tools interpolate between neighbors – more on that next.)
Method 2: PromQL and Histograms
If you’re storing latency as Prometheus histograms, the canonical query is:
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))Reading it inside-out: rate(..._bucket[5m]) computes the per-second increase of each histogram bucket over a 5-minute window; sum(...) by (le) aggregates those bucket counts across instances, grouped by the le (“less than or equal to”) bucket boundary; and histogram_quantile(0.95, ...) estimates the value below which 95% of observations fall.
Because classic histograms bucket observations, the result is an estimate – Prometheus linearly interpolates within the bucket that contains the 95th percentile. [2] If your buckets are coarse around the region where your P95 lives, expect estimation error. Size your buckets with the latencies you actually care about in mind. See the Prometheus histogram_quantile documentation for the full function reference.
Method 3: Reading It Straight From Your Load-Testing Report
Most performance engineers get P95 straight from a load-testing report’s “95th percentile” column. The value to a QA lead is that it’s already computed against the full run – no scripting, no post-processing. RadView’s platform surfaces P50/P90/P95/P99 in its results dashboards by default, so you read the 95th-percentile figure directly against your threshold rather than exporting raw samples and calculating by hand. When you’re eyeballing any tool’s percentile column, sanity-check two things: that the sample size behind it is large enough to be meaningful, and that the reporting window matches the load phase you care about (steady-state, not the ramp-up). Some legacy enterprise suites and open-source tools require a plugin or manual aggregation to get trustworthy tail numbers – worth confirming before you trust the column, as covered in this guide to how to choose a performance testing tool.
The #1 Mistake: You Can’t Average Percentiles
Here’s the error that silently corrupts more dashboards than any other: averaging pre-computed percentiles. You have two servers. Server A reports a P95 of 100ms, Server B reports 900ms. The average is 500ms – so your fleet P95 is 500ms, right?
Wrong, and not “a little off” – statistically meaningless. Gil Tene put it bluntly: “You can’t average percentiles. Period.” [3] The Prometheus docs demonstrate the same trap directly, flagging avg(http_request_duration_seconds{quantile="0.95"}) // BAD! and explaining that “aggregating the precomputed quantiles from a summary rarely makes sense… averaging the quantiles yields statistically nonsensical values.” [2]
Why does 500ms fail? Because the true combined P95 depends on the distributions and traffic volumes behind each server. If Server A handles 95% of traffic and is uniformly fast, the real combined P95 might be ~120ms. If Server B carries most of the load, it could be ~800ms. The number 500 corresponds to nothing. The same trap ruins multi-window aggregation: you cannot compute a 7-day P95 by averaging seven daily P95 values. The correct approach is to preserve histograms and re-aggregate at the bucket level – histogram_quantile(0.95, sum(rate(...[5m]))) sums the raw buckets first, then computes the quantile. [2] Sum the buckets, then take the percentile. Never the reverse.
P95 vs P99 vs P50: Choosing the Right Percentile for Your SLO
Percentiles form a family, and picking the wrong one for your SLO either lets pain slip through or makes you chase outliers you can’t afford to fix. The Google SRE framework grounds this choice in the SLI/SLO/SLA hierarchy and error budgets. [1][4]
What Each Percentile Tells You: A Comparison Table
| Percentile | What it reveals | When to use it |
|---|---|---|
| P50 (median) | The typical user’s experience; a clean regression detector | Baseline health; catching broad slowdowns |
| P90 | Broader coverage; where “most” users sit | Secondary UX target for less critical paths |
| P95 | Standard SLO metric – balances coverage with actionability | General user-facing UX and most SLOs |
| P99 | The slowest 1%; exposes architectural bottlenecks and tail causes | Revenue-critical or latency-sensitive systems |
| P99.9 | Extreme outliers at hyperscale | High-fan-out paths and hyperscale services where the tail dominates |
A Decision Framework: Matching Percentile to Business Risk
The rule of thumb: use P95 for general UX targets, escalate to P99/P99.9 when the tail carries disproportionate business risk or when architecture amplifies it.
- If it’s a general web application or content API → then set the SLO on P95 (e.g., P95 < 300ms).
- If it’s a payment or checkout API where a slow request loses revenue → then set it on P99 (e.g., P99 < 500ms), because the slowest 1% are the transactions you can least afford to lose.
- If it’s a high-fan-out microservice path where one page triggers dozens of subrequests → then track P99 or even P99.9, because tail amplification (next section) means per-service tails compound.
- If it’s an internal batch or non-interactive job → then P50/P90 is often sufficient; chasing the tail here wastes engineering budget.
Tie the choice to your error budget. If your SLO is “99% of requests under 400ms,” you’re implicitly agreeing that 1% can exceed it – that’s a P99 target. Chasing deeper tails (P99.9, P99.99) costs real money in redundancy and engineering effort, so only pay for it where the business case justifies it. [4] Google’s SRE Workbook on implementing SLOs offers practical guidance for setting these targets.
Tail Latency Amplification: Why Microservices Make P95 Worse
Microservices have a nasty property: a single user request often fans out to many backend services, and the end-to-end latency is governed by the slowest subrequest. This is why a fleet of services each with an excellent individual tail can still deliver a terrible aggregate experience – the phenomenon Dean & Barroso formalized in “The Tail at Scale.” [5]
The Fan-Out Math: Small Tails, Big Problems
Suppose a request fans out to N=10 services, and each has a modest 1% chance (p=0.01) of being slow on any given call. What’s the probability that at least one of those ten is slow?
Probability all ten are fast = (1 − 0.01)^10 = 0.99^10 ≈ 0.904.
Probability at least one is slow = 1 − 0.904 ≈ 0.096, or ~9.6%.
Read that again: ten services each with a “great” 1% tail combine to make nearly 10% of your end-to-end requests hit a slow dependency. Your per-service P99 was fine; your aggregate P90 is now a problem. Dean & Barroso documented amplification factors far higher than this in real Google systems, where a request touching thousands of servers is almost guaranteed to hit some slow node. [5] There’s also a subtle measurement trap worth internalizing: the max of your services’ P95 values is not the same as the P95 of the maximum across services – reasoning about “which service dominates the tail” requires looking at the combined distribution, not comparing individual percentiles. See Dean & Barroso’s ‘The Tail at Scale’ research paper for the foundational treatment.
Mitigation Patterns: Hedging, Timeouts, and Circuit Breakers
“The Tail at Scale” catalogs tail-tolerant techniques; three you’ll use most:
- Hedged (backup) requests: after a short delay, send a duplicate request to a second replica and take whichever returns first. This trades a small amount of extra load for a dramatically tighter tail, since you’re no longer hostage to a single slow replica. [5]
- Hard timeouts tied to P99: set the timeout at (or just above) your target P99 so a stalled dependency is abandoned before it dominates the chain. If your P99 target is 500ms, a 600ms hard timeout caps the damage a single hung subrequest can do.
- Circuit breakers: when a dependency’s error or latency rate crosses a threshold, trip the breaker and fail fast (or serve a degraded “good-enough” response) instead of letting every request queue behind a sick service.
What Slow Responses Cost You: Translating P95 Into Revenue and Retention
If you’re a product owner or marketer, here’s the sentence that matters: your P95 is the experience of your unluckiest users, and at scale that group is huge.
Do the arithmetic. If you serve 1,000,000 users a day and your P95 is bad, that’s 50,000 people every single day hitting your slow tail. That’s not an edge case – that’s a mid-sized city’s worth of frustrated users, daily. Frame it that way in a planning meeting and “the slowest 5%” stops sounding ignorable.
The business impact is well documented. Google’s Core Web Vitals research consistently links slower page and response latency to higher bounce rates and lower engagement [6], and performance-impact studies in the “milliseconds make millions” vein have repeatedly tied latency reductions to measurable conversion and revenue gains. [7] The nuance most business dashboards miss: these losses concentrate in the tail, not the average. The users abandoning your checkout aren’t the median-experience users – they’re the ones stuck in that P95/P99 band. Optimize the tail and you’re directly protecting conversion and retention, not chasing a vanity metric.
Optimizing P95 Latency: A Layered, Root-Cause Playbook
Optimizing P95 is fundamentally different from improving average latency. Averages improve when you make the common path faster. The tail improves when you attack variance and outliers. You can double your median throughput and leave a GC-induced P95 spike completely untouched. So the playbook starts with diagnosis, not tuning.
Diagnose Before You Optimize: Finding the Real Tail Cause
Most optimization guides skip the step that actually matters: figuring out what is producing the tail. Common culprits and how they show up in metrics, which you can systematically test and identify as bottlenecks in performance testing:
- Connection-pool exhaustion: P95 spikes correlate with pool-saturation or wait-queue-depth metrics; the tail appears under load, not at idle.
- Garbage-collection pauses: periodic P95 spikes line up tightly with GC pause-duration metrics and stop-the-world event timestamps.
- Slow upstream dependency: the tail tracks a specific downstream service’s latency; segment P95 by dependency to find it.
- Cold caches / cold starts: the tail is worst right after deploys, scale-out events, or traffic bursts, then settles.
Segment your P95 by endpoint, dependency, and region before touching code. Optimizing the wrong layer is how teams burn a sprint and move the tail zero milliseconds.
Caching, Timeouts, and Concurrency Limits That Shrink the Tail
Once you know the cause, match the remedy:
| Root cause | Remedy | Effect |
|---|---|---|
| Connection-pool exhaustion | Right-size the pool; add a wait-queue cap | Cuts queueing-induced tail sharply |
| Slow cold-path requests | Result/edge/vector caching for rare paths | Shrinks the tail without changing the median |
| A single hung dependency | Hard timeout tied to P99 + circuit breaker | Caps worst-case chain latency |
| Overload / thread saturation | Concurrency limits + load shedding | Prevents cascading tail blowups under spikes |
A key distinction: some tactics shrink the tail without touching the median. Caching a rarely hit cold path, for example, rescues the unlucky requests that were recomputing expensive results while leaving your already-fast common path unchanged – a pure P95 win. Contrast that with raising overall throughput, which lifts the median but may do nothing for a GC-driven tail. And per SRE practice, tie hard timeouts to your P99 target so you abandon stalled requests before they dominate. As a rough illustration of the payoff, right-sizing an exhausted connection pool commonly takes a P95 from something like 1.4s down to a few hundred milliseconds – because you’ve removed the queueing, not made the fast path faster.
Validating Your P95 SLO With Load Testing (Before an SLA Breach Costs You)
Here’s a scenario that plays out more than vendors admit: an SLA gets signed committing to a P95 threshold that nobody ever load-tested. The number looked reasonable in a meeting. Then real traffic arrives, the P95 blows past the committed threshold within hours, and the service-credit clauses trigger six-figure penalties before anyone finishes lunch. The fix is boring and effective – prove the target holds under realistic load before you commit to it.
SLA vs SLO vs SLI: Getting the Hierarchy Straight
Three terms, one hierarchy: [1][4]
- SLI (Service Level Indicator): the thing you measure. Example: your measured P95 response time.
- SLO (Service Level Objective): your internal target for that indicator. Example: “P95 < 400ms at peak load.”
- SLA (Service Level Agreement): the contractual promise to a customer, usually with penalties. Example: “P95 < 500ms or we credit 10% of monthly fees.”
Your SLA should always be looser than your SLO, which should always be measurable via your SLI. Load testing is how you confirm the SLI can actually meet the SLO before the SLA locks it in, a relationship explored further in this look at the SLA for performance and load testing.
The 5-Step Workflow: From SLO Target to CI Gate
- Derive the target from the SLO. If the SLO is “P95 < 400ms at peak,” that’s your pass/fail line.
- Model realistic traffic. Match your production workload mix – not just one endpoint. Configure a ramp (e.g., 0 → 2,000 virtual users over 10 minutes), a steady-state peak, and a soak phase (e.g., 30 – 60 minutes) to catch resource leaks and pool exhaustion that only appear over time.
- Run distributed load. Generate load from enough capacity to actually reach peak concurrency. RadView’s platform handles distributed generation across cloud or on-prem and measures P95 across the full transaction chain – browser → API → database – via broad protocol support, rather than only hitting isolated HTTP endpoints.
- Read percentiles correctly. Look at steady-state P95, not the ramp phase, and guard against coordinated omission (next).
- Wire a CI pass/fail gate. Concretely: fail the build if P95 > 400ms at 2,000 concurrent virtual users during steady state. Now every release is checked against the SLO automatically, and a regression can’t sneak into production, which is exactly what integrating performance testing into CI/CD pipelines is designed to enforce.
The built-in percentile dashboard makes step 4 straightforward – you compare the reported 95th-percentile figure directly against your threshold line rather than exporting and recomputing.
Coordinated Omission: The Silent P95 Under-Reporter
Coordinated omission is the reason many load tests under-report the tail and hand you a falsely optimistic P95. Here’s the mechanism: suppose your test harness intends to send a request every 100ms. A response stalls for 2 seconds. During that stall, the sender is blocked and never issues the ~20 requests it should have sent in that window. Those 20 requests – which would have recorded terrible latencies because the system was clearly struggling – simply don’t exist in your dataset. Result: the harness records one slow request instead of twenty, and your P95 looks far better than reality. Gil Tene’s work on this is the reference for why naïve latency measurement misleads. [3] Mitigate it by using a load tool that compensates for coordinated omission (recording the latency a request should have experienced given its intended send time) or by driving load with an open workload model that maintains request rate independent of response times.
P95 by Architecture: Monoliths, Microservices, Serverless, and Edge
P95 behaves differently across stacks, so measure the thing that matches your architecture. In a monolith, P95 is largely a single-point measurement at the application boundary. In microservices, it’s a compound metric across service chains (subject to the amplification math above). Serverless and edge add their own twists.
Serverless and Cold Starts: When P95 and P50 Diverge Hardest
Serverless is where P50 and P95 diverge most violently. A function that answers in 40ms when warm can show a 1.2s P95 when concurrency scales up and the platform spins new containers. Your median stays gorgeous because most invocations hit warm instances; your tail explodes because every scale-out event manufactures cold starts. Test for it deliberately with bursty ramp patterns and concurrency spikes – a gentle, gradual ramp will keep everything warm and hide the exact behavior that will bite you during a real traffic surge.
Microservices and Edge: Measuring the Whole Chain
Across a service chain, per-service P95 values don’t simply add. If Service A has a P95 of 80ms and Service B has a P95 of 90ms and they run sequentially, the chain P95 is not 170ms – the requests that are slow at A aren’t necessarily the same requests that are slow at B, so the combined distribution has to be measured end to end, not summed. Add geographic distribution at the edge and you get regional percentile variation on top. The practical takeaway: measure P95 across the entire transaction chain (browser → API → database) rather than trusting isolated endpoint numbers. Broad protocol coverage is what lets a load test exercise that full chain realistically across on-prem and cloud components in one run.
Frequently Asked Questions About P95 Latency
What is a good P95 latency for a web application or API?
It depends on the interaction type, but useful starting points: a typical backend API often targets a P95 in the 100 – 300ms range, while a full page load target is commonly around 1 – 2 seconds at P95. These are illustrative – validate against your own workload and traffic profile, since a payment API and an analytics dashboard have very different acceptable tails.
Should I use P95 or P99 for my SLOs?
Use P95 when the path is general user-facing UX and you want a stable, actionable target (e.g., a content API at P95 < 300ms). Use P99 when the slowest 1% carry outsized business risk or the architecture amplifies the tail – payment flows, or high-fan-out microservice paths where a single slow subrequest can dominate. Tie the choice to your error budget: a “99% under X” SLO is by definition a P99 target, and chasing deeper tails costs real money, so only pay for it where the business case holds. [4]
Is P95 latency the same as 95th percentile response time?
Yes – identical. “P95 latency” is engineer shorthand; “95th percentile response time” is the formal label you’ll see in report columns and SLA documents. Both mean the response time that 95% of requests complete within.
Can I just ignore the slowest 5%?
Only if that 5% is genuinely nobody. At 1,000,000 daily users, the slowest 5% is 50,000 people every day – and because these are exactly the users most likely to abandon or churn, they’re disproportionately expensive to lose. The tail is where conversion damage concentrates, not the average.
Why might my load test under-report P95?
Most often, coordinated omission: when a slow response stalls the request generator, the requests it should have sent during the stall never get recorded, so the dataset omits the very samples that would have shown the tail. [3] Use a tool that compensates for coordinated omission or drive load with an open workload model that holds request rate steady regardless of response time.
Averages will keep lying to you as long as you keep listening to them. P95 is the antidote: define it correctly (95% of requests, not users), calculate it three ways while never averaging percentiles, choose P95 or P99 based on business risk rather than habit, respect how microservice fan-out amplifies the tail, optimize by attacking variance at its root cause, and – above all – prove your target holds under realistic, coordinated-omission-safe load before you ever sign it into an SLA. Do that, and your dashboard doesn’t get to lie to you anymore.
Latency thresholds and benchmark figures cited in this article are illustrative or drawn from published sources; validate targets against your own workload and traffic profile.
References
- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2017). Site Reliability Engineering – Chapter 4: Service Level Objectives. Google / O’Reilly. Retrieved from https://sre.google/sre-book/service-level-objectives/
- Prometheus Authors. (N.D.). Histograms and summaries (and the
histogram_quantilefunction reference). Prometheus Documentation. Retrieved from https://prometheus.io/docs/practices/histograms/ and
