The 3 Types of SLAs Explained: How to Test Customer-Based, Service-Based & Multi-Level Agreements Under Load

A performance team once shipped a contract-backed service that looked airtight on paper. The response-time clauses were signed, the availability targets agreed, everyone shook hands. Then production traffic hit, latency ballooned past the committed threshold, and the provider ended up owing six figures in service credits – money handed back to the customer because nobody had proven those numbers held up under realistic load before the ink dried [1]. That’s the failure mode this guide exists to prevent.

Here’s the frustrating part: most of the advice you’ll find online can’t even help you get the vocabulary straight. Search “three types of SLAs” and you’ll get pages that confidently list response time, resolution time, and uptime – which are metrics, not structural types at all. The actual three structural types are customer-based, service-based, and multi-level. That single conflation trips up engineers who then design tests against the wrong thing.

This is the SLA guide built for engineers, not lawyers. We’re going to treat your SLA as what it really is: a testable technical specification. You’ll learn how each of the three structural types changes your load-testing scope, how to convert vague contractual promises into concrete pass/fail assertions, how to reconcile conflicting thresholds in multi-level agreements, and how to gate releases so a breach never reaches a customer. Let’s get the foundations right first.

1. Understanding SLA Classifications: Why the ‘Type’ Matters for Performance Testing
   1. SLA vs. SLO vs. SLI: The Hierarchy Engineers Actually Need
   2. Types vs. Metrics: Clearing Up the Web’s Most Common SLA Mistake
   3. Why SLA Structure Dictates Your Testing Scope
2. Type 1: Customer-Based SLAs – One Contract, One Client, Tailored Thresholds
   1. When to Use a Customer-Based SLA
   2. Testing Implications: Per-Client Load Profiles
3. Type 2: Service-Based SLAs – One Standard for Everyone
   1. Representative Workload Modeling and Percentile Targeting
   2. Service-Based vs. Customer-Based: The Testing Cost Trade-Off
4. Type 3: Multi-Level SLAs – Testing the Hierarchy
   1. Decomposing Corporate, Customer, and Internal Tiers into Testable SLIs
   2. Reconciling Conflicting Thresholds in a Single Test Run
      1. Dependency Mapping Across Service Tiers
5. Quick Reference: Mapping Each SLA Type to a Test Strategy
   1. Test Data and CI/CD Integration Patterns by Type
   2. Matching Test Types to SLA Metrics
6. SLA Metrics and Performance Testing KPIs: What to Actually Measure
   1. Response Time & Throughput: From Clause to Assertion
   2. Availability & Error Rate: Proving Endurance and Resilience
7. Validating SLAs with Load Testing: A Governance Lifecycle, Not a One-Off
   1. Stage 1 – Pre-Sign Baseline Validation (Before You Commit)
   2. Stage 2 – Automating SLA Compliance as a CI/CD Release Gate
   3. Stage 3 – Continuous Production Monitoring & the Breach-Detection Maturity Model
8. 7 SLA Testing Pitfalls (and How to Dodge Them)
9. Frequently Asked Questions About SLA Types and Testing
   1. What are the three types of SLAs?
   2. What’s the difference between customer-based and service-based SLAs?
   3. How do you test multi-level SLAs?
   4. Is validating every SLA clause under load always worth the investment?
   5. How does load testing validate SLA compliance?
10. References

Understanding SLA Classifications: Why the ‘Type’ Matters for Performance Testing

An SLA in an IT context is a commitment – usually contractual – about the level of service a provider will deliver, backed by consequences when those commitments are missed. The structural type of that agreement isn’t a semantic nicety. It directly determines how many distinct load scenarios you build, how your test data is shaped, and how much monitoring overhead you carry into production. Get the type wrong and you’ll either over-engineer a test suite for a uniform service or, worse, run one generic test against a dozen clients who each contracted for different thresholds.

Frameworks like ITIL 4 Service Level Management and the ISO/IEC 20000-1 standard formalize how service levels are defined, measured, and reviewed – giving you a governance backbone that ties each SLA clause to a measurable delivery target [2][3]. The canonical taxonomy across these enterprise frameworks is three structural types: service-based, customer-based, and multi-level [2]. Keep that number – three – but keep it attached to structure, not metrics.

SLA vs. SLO vs. SLI: The Hierarchy Engineers Actually Need

Think of it like driving. The SLI (service level indicator) is your speedometer reading – the actual measured value, say your P95 latency right now. The SLO (service level objective) is your internal speed limit – the target you hold yourself to. The SLA is the contract with the traffic cop: exceed it and there are penalties. The Google SRE book puts the distinction bluntly: “An easy way to tell the difference between an SLO and an SLA is to ask what happens if the SLOs aren’t met? If there is no explicit consequence, then you are almost certainly looking at an SLO” [4].

The practical rule: set your SLO tighter than your SLA to build an early-warning buffer. If you promise customers 99.95% availability, hold yourself internally to 99.99%.

Error-budget math makes this concrete. With a 99.9% success SLO, the budget is 100% minus the SLO – 0.1%. Over a four-week window, a service handling 3 million requests gets exactly 3,000 allowed errors before the budget is blown [5]. Framed as time, a 99.9% monthly availability target leaves you roughly 43 minutes of downtime budget. For reference, a real published cloud commitment – Google Compute Engine – targets 99.95% availability [4].

For a full treatment of the hierarchy, the Google SRE Book: Service Level Objectives is the authoritative reference.

Types vs. Metrics: Clearing Up the Web’s Most Common SLA Mistake

Let’s kill the confusion directly. These are two different lists:

The three structural SLA types:

• Customer-based (tailored to one specific client)
• Service-based (uniform across all users of a service)
• Multi-level (layered across corporate, customer, and service tiers)

Common performance metrics you validate:

• P95 / P99 response time
• Throughput (requests per second)
• Uptime / availability (%)
• Error rate (%)

Many ITSM and help-desk sources – including widely-cited “3 types of SLA” explainers – blur these into one list, presenting response time, resolution time, and uptime as if they were the three types [6]. They aren’t. The structural type describes who the agreement applies to and how it’s organized; the metrics describe what you measure to prove it, and understanding which performance metrics matter keeps that measurement honest. Every structural type uses some mix of those metrics. ITIL 4 keeps the taxonomy on the structural side [2], and that’s the framing that actually drives test design.

Why SLA Structure Dictates Your Testing Scope

Here’s the operational chain reaction. A service-based SLA means one uniform commitment, so you build one reusable load-test suite validating one shared threshold. A customer-based SLA with 12 enterprise clients – each with their own peak windows, geographies, and thresholds – can require up to 12 distinct scenario sets, each with individual pass/fail criteria and separate monitoring dashboards. That’s a 12x difference in test-maintenance surface area, and it’s decided entirely by the structural type you signed.

This is where enterprise tooling earns its keep. Maintaining a dozen parallel scenario sets – each replicating a different client’s protocol stack – demands test organization and broad protocol coverage. WebLOAD’s support for 150+ protocols lets you replicate that diversity without switching tools per client, and ISO/IEC 20000-1 gives you the governance structure to keep each agreement’s measurable targets traceable [3].

Type 1: Customer-Based SLAs – One Contract, One Client, Tailored Thresholds

Picture a SaaS provider onboarding a Fortune 500 client whose contract demands P95 response time under 200ms during their 9am regional trading peak – stricter than anything the provider offers its standard customers. That’s a customer-based SLA: a fully customized agreement built around one client’s specific needs, rather than a uniform standard applied across everyone [7]. They’re the norm in enterprise B2B software, where large accounts negotiate bespoke terms.

Because the thresholds are client-specific, your baseline performance targets have to be established per customer – NIST guidance on setting performance baselines applies individually here, not globally [8]. And since each client’s environment differs, replicating it faithfully matters: the load test that proves the 200ms peak has to model that client’s actual traffic mix and protocol stack. Broad protocol flexibility – RadView’s platform covers 150+ – is what lets you reproduce diverse client environments without compromise.

For authoritative context on the cloud service models that underpin these per-customer commitments, see the NIST Definition of Cloud Computing (SP 800-145).

When to Use a Customer-Based SLA

Use this decision cue: if a client’s annual contract value crosses a threshold that justifies dedicated engineering attention – say, exceeding $500K/year – or they require a single-tenant environment, unique compliance controls, or bespoke integrations, then a customer-based SLA is warranted. ITIL 4 Service Level Management frames these as agreements customized to individual customer requirements rather than standardized service offerings [2]. The added testing cost only pays off when the client’s needs genuinely diverge from your standard service.

Testing Implications: Per-Client Load Profiles

Each customer’s traffic mix, geography, peak windows, and protocol stack demands its own scenario. Consider two clients under the same provider:

• Client A: 5,000 concurrent users, P95 < 300ms, mostly REST/JSON API traffic during North American business hours.
• Client B: 800 concurrent users, P99 < 150ms with a stricter 99.99% uptime clause, running a mix of WebSockets, JSON APIs, and legacy SOAP endpoints across European regions.

You can’t validate both with one script, and knowing how to load test concurrent users accurately for each profile is what keeps the numbers defensible. Multi-protocol simulation lets a single platform replicate Client B’s mixed stack while a separate scenario handles Client A. The SRE practice of “bucketing by tier” – maintaining distinct thresholds per grouping – is the model for keeping these organized without collision [5].

Type 2: Service-Based SLAs – One Standard for Everyone

A service-based SLA applies uniform performance standards to a service regardless of who uses it. This is the model behind public cloud platforms, CDNs, and open APIs. A public cloud compute service committing to 99.95% monthly availability [4] doesn’t negotiate that figure per customer – every user gets the same promise, so you validate it once with a single representative test suite.

The upside for your test strategy is obvious: one reusable suite, one shared threshold, dramatically lower maintenance overhead than the per-client approach. You model the average user’s workload and target a percentile – typically P95 latency under a baseline workload – to confirm the shared commitment holds. The trick is defining “average” honestly, because a looser external SLA (99.95%) should sit above a tighter internal SLO (99.99%) to give you a buffer before penalties trigger [4].

Our own deep-dive on the SLA for performance and load testing walks through this validation in more detail, and the Google SRE Book: Service Level Objectives explains how service-level objectives are defined and measured.

Representative Workload Modeling and Percentile Targeting

Build one “average user” workload model that mirrors real traffic distribution, then assert against percentiles – not averages. Here’s why the distinction is non-negotiable. Imagine a dataset where your mean response time is 180ms. Looks healthy. But the P99 is 950ms. That means 1 in every 100 requests takes nearly a full second – a broken experience for a meaningful slice of users, entirely hidden by the average. As the Google SRE book states, “a simple average can obscure these tail latencies… a high-order percentile, such as the 99th or 99.9th, shows you a plausible worst-case value” [4]. SLA compliance reporting that validates a shared threshold across all simulated users is what catches this.

For the mechanics of measuring response time correctly, MDN Web Docs: Web Performance Fundamentals is a solid reference.

Service-Based vs. Customer-Based: The Testing Cost Trade-Off

Dimension	Service-Based SLA	Customer-Based SLA
Definition	Uniform terms for all users of a service	Tailored terms for one specific client
Best use case	Cloud platforms, CDNs, public APIs	High-value enterprise B2B accounts
Testing implication	1 reusable test suite, shared threshold	N scenario sets (one per client), distinct thresholds
Monitoring complexity	Low – single dashboard	High – per-client dashboards and alerts

The structural definitions here are grounded in ITSM authority and ITIL 4 [7][2]. The engineering takeaway competitors skip: choosing customer-based over service-based isn’t just a contract decision – it’s committing to N times the test-maintenance and monitoring burden.

Type 3: Multi-Level SLAs – Testing the Hierarchy

Multi-level SLAs are the toughest to validate. They layer commitments across tiers – typically corporate, customer, and service levels – reflected in ITIL 4’s multi-level service support models [2]. A telecommunications provider might hold a corporate uptime SLA of 99.9%, a customer-tier response-time SLA of P95 < 250ms, and an internal SLO of 99.95%, all active simultaneously. Validating this requires an integrated, multi-scenario test suite that exercises every tier and reconciles thresholds that sometimes conflict.

The SRE workbook’s “bucketing by tier” model is directly applicable: a Premium availability SLO of 99.99% alongside a Free tier of 99.9%, plus graded latency targets like “90% of requests faster than 100ms, and 99% faster than 400ms” [5]. That six-figure service-credit disaster from our intro? It happened precisely because multi-tier thresholds were never validated together under load [1]. Coordinated, tiered SLA reporting – running all tiers in one test and marking pass/fail per tier – is what prevents that outcome. For decomposing objectives across tiers, the Google SRE Book: Service Level Objectives is the reference.

Decomposing Corporate, Customer, and Internal Tiers into Testable SLIs

Every tier becomes a concrete assertion once you decompose it into a measurable indicator:

• Corporate tier: 99.9% availability across the platform → SLI = successful request ratio over the test window.
• Customer tier: P95 < 250ms → SLI = 95th-percentile response time under contracted concurrency.
• Internal tier: error rate < 0.1% → SLI = failed-request ratio, giving your team a tighter buffer than the customer sees.

The SRE workbook’s distinction between SLI specification (what you intend to measure) and SLI implementation (how you actually measure it) keeps these honest across tiers [5].

Reconciling Conflicting Thresholds in a Single Test Run

Here’s the gap no generic guide covers. Suppose your corporate SLA demands 99.9% uptime while your customer tier demands P95 < 200ms. Under a spike, the system might stay available (satisfying the corporate tier) while latency degrades past 200ms (breaching the customer tier). A single coordinated test with tiered reporting flags exactly which tier fails first – you’d see the corporate availability tier still green while the customer response-time tier flips red, telling you the failure is latency, not outage. A multi-tier compliance report with per-tier pass/fail markers turns that reconciliation into a glance rather than a forensic investigation. Skip it, and you inherit the six-figure post-mortem [1].

Dependency Mapping Across Service Tiers

Lower-tier breaches cascade. Map the chain: an authentication service P99 spike → checkout API P95 breach → corporate transaction-success SLA violation. Without dependency mapping, a corporate SLA can fail while every dashboard for the corporate service itself looks healthy. Integrated component monitoring across servers, databases, network, and load balancers lets you isolate which upstream dependency actually triggered the tier breach, rather than guessing.

Quick Reference: Mapping Each SLA Type to a Test Strategy

Use this as your at-a-glance decision aid:

• Customer-based → Dedicated test environment per client + per-client thresholds. Model each client’s protocol stack and peak window separately.
• Service-based → Single reusable suite. Target P95 under a representative average-user workload; keep external SLA looser than internal SLO.
• Multi-level → Integrated suite with tiered reporting + dependency map. Run all tiers in one coordinated test; flag per-tier pass/fail.

Test-organization features that let you group, reuse, and tier scenarios keep all three manageable. For the broader planning discipline, see our strategic load test planning guide.

Test Data and CI/CD Integration Patterns by Type

Data and pipeline triggers differ per type. Customer-based needs client-representative data (their user distribution, their record volumes). Service-based needs realistic average-user data and a simple gate – trigger a headless run on every merge to main, fail the build if P95 > 500ms. Multi-level needs coordinated cross-tier data so a corporate-tier assertion and a customer-tier assertion share one consistent traffic model. Aligning these gates with DORA metrics and the SRE practice of gating on burn-rate turns integrating performance testing into CI/CD pipelines into governance [4].

Matching Test Types to SLA Metrics

SLA Metric	Test Type	Sample Threshold
Response time	Load test	P95 < 300ms at target concurrency
Throughput	Capacity test	2,000 req/s sustained
Availability	Soak / endurance	99.9% success across an 8-hour run
Error rate	Stress test	< 0.1% errors past expected peak

This load/stress/soak/spike taxonomy is standard across neutral performance-testing methodology and maps cleanly to the metrics your SLA actually names.

SLA Metrics and Performance Testing KPIs: What to Actually Measure

An SLA clause only becomes useful when it’s a pass/fail assertion. ITSM standards define the core metrics as response time, resolution time, and system availability [9] – now translate those into engineering terms: P99 < 200ms, 2,000 req/s sustained throughput, 99.95% availability, each tied to the test type that proves it. Percentile measurement is the discipline that keeps latency KPIs honest [4], and error-budget math frames your error-rate ceiling [5]. SLA validation dashboards that map results directly to clauses are what turn a test run into contract evidence. Our engineer’s guide to load testing KPIs goes deeper, and MDN Web Docs covers response-time measurement fundamentals.

Response Time & Throughput: From Clause to Assertion

A contract that says “responses should be fast” is untestable. Convert it: “P95 < 300ms while sustaining 2,000 req/s.” Now it’s a binary assertion your test either passes or fails, and an SLA validation dashboard shows the result against the committed threshold at a glance – no interpretation required.

Availability & Error Rate: Proving Endurance and Resilience

Availability targets demand soak testing, because memory leaks and resource exhaustion only surface over time. Run an 8-hour soak and hold the error budget: at a 99.9% SLO, that’s a maximum of 3,000 errors per 3 million requests [5]. Error-rate thresholds get validated with stress tests that deliberately push past expected peak – you want to know your error rate at 150% of forecast load, not just at forecast.

Validating SLAs with Load Testing: A Governance Lifecycle, Not a One-Off

SLA validation isn’t a single test – it’s a lifecycle with three stages, each producing an evidence artifact. The RadView methodology frames it clearly: simulate realistic traffic, confirm thresholds are achievable, and prevent penalties before sign-off [1]. Layer in burn-rate alerting and you get predictive early warning. The SRE workbook’s recommended multi-burn-rate parameters for a 99.9% SLO: page when the 1-hour burn rate hits 14.4x (consuming 2% of budget), and open a ticket when the 3-day burn rate is 1x (consuming 10%) [10]. Our performance engineering hub frames this as a discipline, and the SRE Workbook: Alerting on SLOs details the recipes.

Stage 1 – Pre-Sign Baseline Validation (Before You Commit)

Before signing, prove the threshold is achievable and attach the evidence to the contract. The artifact: a validation report showing, for example, P95 = 240ms against a committed P95 < 300ms at target concurrency – a documented margin the customer can see. This is the exact step whose omission cost one team six figures in service credits [1]. A validation report generated from the test run becomes your sign-off document.

Stage 2 – Automating SLA Compliance as a CI/CD Release Gate

Gate releases on SLA pass/fail. Unlike ticketing-SLA automation (which tracks help-desk response times), performance-SLA automation blocks a build when the code can’t meet the contract. A tool-neutral gate looks like:

sla_gate:
  run: load-test --scenario service-sla --users 2000
  evaluate:
    - if: p95 > 500ms
      then: exit 1   # block release
    - if: error_rate > 0.01
      then: exit 1   # block release
  report: sla-compliance-report.html

Wire this into your pipeline with a test runner and it auto-generates a compliance report on every run, aligning your release cadence with DORA delivery metrics [4].

Stage 3 – Continuous Production Monitoring & the Breach-Detection Maturity Model

Detection maturity climbs a spectrum:

1. Reactive – you learn of a breach from a customer complaint or penalty invoice. Worst case.
2. Real-time – alert at 80% of error budget consumed.
3. Predictive – warn hours to days ahead on a rising burn-rate trend.
4. Shift-left prevention – catch the breach in pre-production load testing so it never reaches a customer at all.

Production End User Experience and SLA compliance monitoring covers the top of that spectrum, but the workbook makes the strategic point: “The only way to defend this level of reliability is to design the system so that the chance of a 100% outage is extremely low” [10]. Pre-production testing is how you engineer that low probability. See the SRE Workbook: Alerting on SLOs for the alerting mechanics.

7 SLA Testing Pitfalls (and How to Dodge Them)

The traps that unify business and engineering failure modes – most guides cover one or the other, never both:

1. Reporting averages instead of percentiles. A 180ms average with a 950ms P99 means your SLA looks met while 1 in 100 users has a broken experience [4]. Always assert on percentiles.
2. Ignoring cold-start scenarios. First-request latency after a scale event or cache flush often blows past steady-state thresholds. Test the cold path explicitly.
3. Overlooking geographic distribution. A single-region test won’t catch the latency your APAC users actually see. Distribute load generation.
4. Single-tier tunnel vision in multi-level SLAs. Validating the corporate tier while ignoring dependency SLAs lets a lower-tier breach cascade silently into a corporate violation. Map the dependency chain.
5. Unrealistic (too-clean) test data. Synthetic data that never triggers edge-case code paths inflates your pass rate. Use production-representative data.
6. Insufficient soak duration. Memory leaks hide in short runs. An 8-hour-plus soak exposes what a 10-minute test never will.
7. Metrics met, customers unhappy. Over-indexing on individual process SLAs can pull focus from overall satisfaction – NPS and CSAT can slide even while every SLA clause is technically green [11]. Pair SLA metrics with CX metrics.

AI-assisted scenario generation helps surface the scenarios teams routinely overlook – cold starts, geographic edge cases – improving SLA coverage without hand-building every path. Our guide to common load testing mistakes expands on the technical traps, and MDN Web Docs covers percentile context.

Frequently Asked Questions About SLA Types and Testing

What are the three types of SLAs?

Customer-based, service-based, and multi-level. These are structural types – how the agreement is organized and who it applies to. They are not the same as response time, resolution time, and uptime, which are metrics you measure within any type. The taxonomy is grounded in ITIL 4 Service Level Management [2].

What’s the difference between customer-based and service-based SLAs?

A service-based SLA applies one uniform standard to every user of a service (think a cloud platform’s 99.95% availability for all customers). A customer-based SLA is tailored to one specific client’s needs – different thresholds, environments, and peak windows [7]. The testing consequence: service-based needs one reusable suite; customer-based needs a distinct scenario set per client.

How do you test multi-level SLAs?

Decompose each tier (corporate, customer, internal) into a measurable SLI, build an integrated test suite that exercises all tiers in one coordinated run, and use tiered reporting to flag per-tier pass/fail. Critically, map dependencies so a lower-tier breach doesn’t cascade unnoticed into a corporate-tier violation.

Is validating every SLA clause under load always worth the investment?

Not always – and this is where honesty matters. For a low-value, easily-renegotiated service-based SLA, exhaustive per-scenario validation can cost more than the penalty risk it prevents. But for customer-based and multi-level agreements with six-figure penalty exposure, pre-sign baseline validation is the cheapest insurance you’ll ever buy [1]. Match validation rigor to penalty exposure.

How does load testing validate SLA compliance?

It converts each SLA clause into a measurable pass/fail assertion under realistic traffic – for example, validating P95 < 300ms at 2,000 req/s before contract sign-off. This proves the threshold is achievable before penalties can ever trigger, rather than discovering the gap in production. Our SLA for performance testing deep-dive walks through the full workflow.

The single most valuable shift you can make is to stop treating your SLA as a legal artifact and start treating it as a testable technical specification. Once you’ve clarified that the three structural types – customer-based, service-based, and multi-level – are distinct from the metrics you measure, everything downstream gets sharper: your test scope, your thresholds, your pass/fail gates. And validation isn’t a one-time event before signing – it’s a lifecycle running from pre-sign baseline proof, through per-release CI/CD gates, into continuous production monitoring. That’s how a six-figure penalty risk gets caught before it ever reaches a customer.

Multi-level SLAs in particular reward enterprise-grade tooling: broad protocol coverage, integrated component monitoring, tiered SLA reporting, and AI-assisted scenario generation coordinate testing across service tiers in ways point solutions struggle to match. Just remember – no testing is truly “self-driving.” AI accelerates coverage and correlation, but human review of thresholds and results stays essential.

Ready to put this into practice? Download an engineering-grade SLA validation report template with P95, throughput, and error-budget clauses, then pick one signed SLA clause this week and map it into a reproducible test scenario. When you’re ready to see per-tier pass/fail reporting on a real multi-level agreement, request a demo and watch it run.

Disclaimer: This article provides technical, engineering-focused guidance on SLA validation and is not legal advice. Contractual SLA language and penalty clauses should be reviewed by qualified legal counsel before signing. All performance figures are illustrative examples drawn from cited sources or representative test scenarios, not guaranteed outcomes.

References

1. RadView. (N.D.). In the Spotlight: The SLA for Performance and Load Testing. RadView Software. Retrieved from https://www.radview.com/blog/in-the-spotlight-the-sla-for-performance-and-load-testing/
2. Axelos. (N.D.). ITIL 4 Service Level Management. Axelos / ITIL 4 publications.
3. International Organization for Standardization. (N.D.). ISO/IEC 20000-1: Information technology – Service management – Part 1: Service management system requirements.
4. Jones, C., Wilkes, J., Murphy, N., & Smith, C. (Ed. Beyer, B.). (2017). Site Reliability Engineering, Chapter 4: Service Level Objectives. O’Reilly Media / Google, Inc. Retrieved from https://sre.google/sre-book/service-level-objectives/
5. Thurgood, S., Ferguson, D., Hidalgo, A., & Beyer, B. (2018). The Site Reliability Workbook, Chapter 2: Implementing SLOs. O’Reilly Media / Google, Inc. Retrieved from https://sre.google/workbook/implementing-slos/
6. Alloy Software. (N.D.). What Are the 3 Types of SLA?. Alloy Software. Retrieved from https://www.alloysoftware.com/blog/what-are-the-3-types-of-sla/
7. Vivantio. (N.D.). Customer-Based SLAs. Vivantio. Retrieved from https://www.vivantio.com/blog/customer-based-sla/
8. National Institute of Standards and Technology. (2011). NIST SP 800-145: The NIST Definition of Cloud Computing. NIST. Retrieved from https://csrc.nist.gov/pubs/sp/800/145/final
9. Freshworks. (N.D.). SLA Metrics: How to Measure & Monitor SLA Performance. Freshworks ITSM. Retrieved from https://www.freshworks.com/itsm/sla/metrics/
10. Thurgood, S., Frame, J., Lenton, A., Quinito, C., Tolchanov, A., & Trdin, N. (2018). The Site Reliability Workbook, Chapter 5: Alerting on SLOs. O’Reilly Media / Google, Inc. Retrieved from https://sre.google/workbook/alerting-on-slos/
11. Calero. (N.D.). The Pitfalls of Service Level Agreements and How to Avoid Them. Calero. Retrieved from