SRE and reliability glossary

Site Reliability Engineering (SRE) concepts tell you whether a load test result is acceptable. This page maps SRE terms to load testing practice so you can use test results as real release signals.

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.” If you meet your SLOs, you can trust that the service behaves as designed.

See the canonical card: SLO in the SEO Glossary.

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

SLA (Service Level Agreement)

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

In MaxoPerf: you can encode SLA thresholds as failure criteria, the same as SLOs. In practice, set failure criteria at SLO levels (tighter), not SLA levels. A failing test then warns you before you breach the customer promise.

Error budget

An error budget is the amount of service degradation you are allowed before an SLO is breached. You calculate it 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 in the SEO Glossary.

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

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 is rejected or starts to queue, so latency climbs and errors appear.

In MaxoPerf: saturation shows up in test results as the point where p95 latency curves sharply upward or error rate starts to climb. Match this point to the VU/RPS level to find the practical capacity ceiling.

Bottleneck

A bottleneck is the saturating resource that limits overall system throughput. The most constrained component sets the system’s capacity ceiling, however much headroom every other component has.

In MaxoPerf: you find bottlenecks by lining up 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. You can export MaxoPerf run results and compare them with your observability stack.

Scalability

Scalability is a system’s ability to keep acceptable performance as load increases, by scaling resources (horizontal or vertical) in proportion. 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) points to a scalability limit, often a bottleneck in a shared resource like a database or a single-threaded worker.

Capacity planning

Capacity planning estimates how much infrastructure you need to serve a projected traffic level while meeting SLO targets. Load testing is a key input, because it measures 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

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

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

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

In MaxoPerf: browser-based (Selenium/WebDriver) test runs that simulate real user page loads measure Core Web Vitals. Run these tests next to API load tests to cover the full user experience. A fast API under load does not help much if the browser renders slowly.

Burn rate

Burn rate is how fast you spend an error budget compared with the allowed rate. A burn rate of 1.0 means you spend 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: if you see error rate or latency violations during a load test, 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

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

In MaxoPerf: use failure criteria to encode reliability targets directly in the test. The test then describes itself. Anyone who runs it sees what the service must achieve, as well as whether it passed.

Where to go next

Metrics and results glossary: p95/p99, error rate, throughput.
Foundations: baselines, SLOs, and error budgets: worked example.
SLO in the SEO Glossary: canonical SLO card.
Error budget in the SEO Glossary: canonical error budget card.
Core Web Vitals in the SEO Glossary: canonical Core Web Vitals card.