Skip to content
MaxoPerf MaxoPerf docs

SRE and reliability glossary

Site Reliability Engineering (SRE) concepts provide the framework for deciding whether a load test result is acceptable. This page connects SRE vocabulary to load testing practice so you can use test results as genuine release signals.

SLO (Service Level Objective)

Section titled “SLO (Service Level Objective)”

A Service Level Objective is an internal, measurable target for a service’s behavior: “99.9% of requests complete in under 500ms over a 30-day window” or “error rate stays below 0.1% in any rolling hour.” SLOs are the engineering targets that, if met, give you confidence the service is behaving as designed.

See the canonical card: SLO — SEO Glossary.

In MaxoPerf: encode your SLOs as failure criteria (e.g. p95 < 500ms, error rate < 0.1%). A test that trips a failure criterion means the build would violate the SLO at that traffic level — a clear release gate signal. Treat SLO thresholds as non-negotiable inputs to test design, not optional targets.

SLA (Service Level Agreement)

Section titled “SLA (Service Level Agreement)”

A Service Level Agreement is a contractual commitment to customers — an externally promised level of service (uptime, latency, support response time). SLAs are typically less strict than SLOs; teams use the gap as a safety buffer.

In MaxoPerf: SLA thresholds can be encoded as failure criteria just like SLOs. The practical recommendation: set failure criteria at SLO levels (tighter), not SLA levels, so a failing test is a warning before you breach the customer promise.

Error budget

Section titled “Error budget”

An error budget is the quantified amount of service degradation you are allowed before an SLO is breached. It is calculated as (1 − SLO target) × time window.

Example: a 99.9% latency SLO over 30 days gives ~43 minutes of allowed violations per month. Releases, maintenance windows, and incidents all consume this budget.

See the canonical card: Error budget — SEO Glossary.

In MaxoPerf: a load test that shows sustained p95 latency violations is consuming your error budget during testing — before any real traffic. Use the failure criteria to quantify this: “this build, at 300 VUs, would consume the full monthly budget in 2 hours.” That converts a vague “performance is worse” finding into a concrete release decision.

Saturation

Section titled “Saturation”

Saturation is the point at which a resource (CPU, memory, network bandwidth, thread pool, connection pool, queue depth) reaches its maximum capacity. Beyond saturation, new work cannot be accepted or starts to queue, causing latency to climb and errors to appear.

In MaxoPerf: saturation appears in test results as the inflection point where p95 latency curves upward sharply or error rate begins to climb. Correlate this point with the VU/RPS level to understand the practical capacity ceiling.

Bottleneck

Section titled “Bottleneck”

A bottleneck is the saturating resource that limits overall system throughput. The system’s capacity ceiling is set by its most constrained component, regardless of how much headroom every other component has.

In MaxoPerf: bottlenecks are identified by correlating test results with infrastructure metrics (CPU, memory, DB connections, external API latency). The load test tells you when performance degrades; the infrastructure metrics tell you why. MaxoPerf run results can be exported and correlated with your observability stack.

Scalability

Section titled “Scalability”

Scalability is a system’s ability to maintain acceptable performance as load increases — by scaling resources (horizontal or vertical) proportionally. A system scales linearly if doubling resources roughly doubles throughput.

In MaxoPerf: measure scalability by running the same test at multiple load levels and comparing the results. Non-linear degradation (e.g. throughput plateaus while latency spikes) indicates a scalability limitation, often a bottleneck in a shared resource like a database or a single-threaded worker.

Capacity planning

Section titled “Capacity planning”

Capacity planning is the process of estimating how much infrastructure is needed to serve a projected traffic level while meeting SLO targets. Load testing is a key input: it determines the maximum throughput per unit of resource.

In MaxoPerf: use breakpoint tests to find the capacity ceiling, then use that data to calculate how many runners (or application instances) you need at projected peak traffic plus a safety margin.

Core Web Vitals

Section titled “Core Web Vitals”

Core Web Vitals are Google’s user-centric performance metrics for web pages:

  • LCP (Largest Contentful Paint) — loading performance; how long until the main content appears.
  • INP (Interaction to Next Paint) — interactivity; how quickly the page responds to user input.
  • CLS (Cumulative Layout Shift) — visual stability; how much the page layout shifts unexpectedly.

See the canonical card: Core Web Vitals — SEO Glossary.

In MaxoPerf: Core Web Vitals are measured via browser-based (Selenium/WebDriver) test runs that simulate real user page loads. Use these tests alongside API load tests to cover the full user experience: an API that is fast under load is only half the story if the browser rendering is slow.

Burn rate

Section titled “Burn rate”

Burn rate is the speed at which an error budget is being consumed relative to the allowed rate. A burn rate of 1.0 means you are consuming the budget at exactly the pace that uses it all by the end of the window. A burn rate of 10.0 means you will exhaust the budget in one-tenth of the remaining time.

In MaxoPerf: during a load test, if error rate or latency violations are observed, calculate the implied burn rate: “if this error rate continued for a full month, how much of the 30-day budget would it consume?” High burn rate during a load test is a hard release blocker.

Reliability target

Section titled “Reliability target”

A reliability target is the summary performance goal for a service expressed as a combination of availability, latency, and error rate. Load testing validates the reliability target under load.

In MaxoPerf: use failure criteria to encode reliability targets directly in the test. This makes the test self-describing: anyone running it can see what the service is expected to achieve, not just whether it passed.

Where to go next

Section titled “Where to go next”