Klaus runs a popular retail website. He wonders if his website is meeting his customers’ expectations. If not, how does Klaus build features to further improve customer satisfaction?

To relieve Klaus’s uncertainty, he can tie his business goals and objectives to the data he is receiving. This is where SLOs, SLIs, and SLAs can come in.

Service Level Objective (SLO)

A Service Level Objective is a range of valid measurements for a metric. An SLO might define that the page response time should be less than 100 milliseconds. Measurements going outside of these ranges tend to require action. SLOs might be defined in terms of:

  • Latency
  • Availability
  • Error rate
  • And many more metrics!

A goal is only helpful if we know where we are in relation to it. While an SLO defines where we want to be, and SLI says where we are now.

Service Level Indicator (SLI)

A Service Level Indicator is the current measurements of a metric related to an SLO. Let’s say that one of our SLOs is that response time should be less than 100 milliseconds. Our system measures that current load times are approximately 75 milliseconds. Our SLI for that SLO would be within a valid range.

SLOs and SLIs might be useful for internal performance, but what of promises we make to consumers? Our next term, the SLA, is for this purpose.

Service Level Agreement (SLA)

A Service Level Agreement is a contract with consumers. Not every business will have an SLA, as they carry a degree of legal responsibility. SLA binds the business to the level of expected service promised to a business’s customers. An SLA might define that a business’ services be available 99.99% of the time. While breaking an SLO is an issue, breaking an SLA is a major problem. A team would want to take corrective action far before an SLA is breached.

SLOs, SLIs and SLAs allow businesses to tie promises and goals to the data coming from their systems. Using these terms make it much more clear when a system metric is jeopardizing the health of a business.


Bloop Co has designed their alerts to occur just before their SLA is broken. What might be a cause for concern with this strategy?

See the answer!
Receiving alerts when performance jeopardizes the SLA is not best practice. Breaking an SLA spells trouble. Therefore, alerts should be sent sooner. Alerts should be sent when a malfunction in the system is breaking an SLO.

We now understand how business objectives are tied to metrics. But that leaves the question of how we can gather that information and view it in a digestible way?

Take this course for free

Mini Info Outline Icon
By signing up for Codecademy, you agree to Codecademy's Terms of Service & Privacy Policy.

Or sign up using:

Already have an account?