• SLA – Service Level Agreement
• SLO – Service Level Objective
• SLI – Service Level Indicator

At first, I found these terms confusing. They sound similar, and all three are related to how reliably a service performs.

I could remember their full forms, but remembering the full forms wasn't the same as understanding what they actually meant.

So I decided to understand them using examples from everyday life instead of trying to memorise technical definitions.

Let's start with something we have all experienced.

1. What Is an SLI (Service Level Indicator)?

What actually happened?

Imagine you are a student.

You prepare for an exam, write it, and finally receive your marks.

You scored 85 out of 100.

Now, what does 85 tell you?

It tells you your actual result.

You cannot say you scored 90 just because you wanted to. Your marks show what actually happened.

That's the basic idea behind SLI.

Now let's connect this to an application.

Imagine you are running an online shopping application. Customers visit your website to browse products, add items to their carts and make payments.

How would you know whether your application is performing well?

You need to measure it.

For example:

• How many customer requests were successful?
• How many requests failed?
• How quickly did the application respond?
• Was the application available when customers needed it?

These are things an engineering team can measure.

Let's take a simple example.

Your application receives 1,000 requests.

Out of those, 990 requests are successful.

Your success rate is:

Success Rate = (Successful Requests / Total Requests) × 100

= (990 / 1,000) × 100

= 99%

That 99% is the observed value of an SLI (Service Level Indicator).

It gives the team an actual measurement of how the application is performing.

Remember:

SLI = Actual measurement.

It tells us what actually happened.

2. What Is an SLO (Service Level Objective)?

What do we WANT to achieve?

Let's continue with our exam example.

Before your exam, you decided:

"I want to score at least 90 marks."

That is your target.

But when the results came out, you scored only 85.

Let's look at the difference:

• Your target = 90 marks.
• Your actual result = 85 marks.

You wanted 90, but achieved 85.

This is the difference between what you want to achieve and what actually happened.

The same idea applies to applications.

Imagine your engineering team decides:

"We want at least 99.9% of customer requests to be successful over a 30-day period."

This is an SLO (Service Level Objective).

It is the target the team sets for the application.

Now imagine the actual success rate is only 99.5%.

What does that tell us?

The team wanted to achieve 99.9%, but the actual result was 99.5%.

The target was not achieved.

This gives engineers a reason to investigate what went wrong and where improvements are needed.

Remember:

SLO = Target.

It tells us what we WANT to achieve.

3. What Is an SLA (Service Level Agreement)?

What did we PROMISE the customer?

Now let's move away from the exam example.

Imagine you hire a school bus service for your child.

The transport company makes a formal agreement with you.

It promises to pick up your child at 8:00 AM.

The agreement also explains what happens if the company fails to provide the agreed service.

This is more than just setting a target.

It is a promise made to another person, with agreed conditions.

That's the basic idea behind SLA.

Let's bring this into the world of applications.

Imagine you run an online shopping application, and another company depends on your application for its business.

You make a formal agreement with that company:

"We promise at least 99% monthly availability. If we fail to meet this commitment, eligible customers may receive service credits according to the agreement."

This is an SLA (Service Level Agreement).

An SLA generally explains:

• What level of service is promised.
• How the service will be measured.
• The period over which it will be measured.
• What conditions or exclusions apply.
• What happens if the agreed commitment is not met.

The important thing here is that an SLA is a formal agreement between a service provider and its customer. It is not just a number or an internal target.

Remember:

SLA = Promise or formal agreement with the customer.

It tells us what we PROMISED the customer.

4. How Are SLI, SLO and SLA Different?

We have understood each term separately. Let's see how they work together in a real application.

Imagine you own an online shopping application.

Your engineering team measures its performance, sets a reliability target, and makes a commitment to customers.

Here is a simple example:

Now look at those numbers again.

• Actual availability (SLI) = 99.5%.
• Target availability (SLO) = 99.9%.
• Customer commitment (SLA) = 99%.

What does this mean?

Our application is working 99.5% of the time.

But our internal target is 99.9%, so we haven't achieved our target.

However, our customer commitment is 99%, so we are still meeting our SLA.

Interesting, right?

This is why companies often set their internal SLO stricter than their customer-facing SLA.

They don't want to wait until customers experience a service-level violation before taking action.

The internal target gives the engineering team room to identify problems and improve reliability before the customer commitment is affected.

5. What Is an Error Budget, and How Does It Relate to SLO?

When I started understanding SLO, I came across another term: Error Budget.

Instead of treating it as another complicated definition, let's continue with the same example.

Imagine your team has set an SLO of 99.9% availability over 30 days.

Does this mean your application must work every second of those 30 days without any interruption?

Not necessarily.

A 99.9% availability target allows a small amount of downtime.

Let's calculate it.

A 30-day month has:

30 × 24 × 60 = 43,200 minutes.

If the application is expected to be available 99.9% of the time, the remaining 0.1% is the downtime allowance.

43,200 × 0.1% = 43.2 minutes.

So, your application can experience approximately 43.2 minutes of downtime in that 30-day period and still meet its 99.9% availability target, assuming the SLO uses this measurement method and counts downtime across the full period.

That allowance is called the Error Budget.

But why do engineering teams need this?

Think about what happens in a real DevOps environment.

Teams regularly:

• Deploy new application versions.
• Release new features.
• Update configurations.
• Fix bugs.
• Make infrastructure changes.

Every change can introduce some risk.

If the team keeps making changes without considering reliability, the application may become unstable.

Error Budgets help teams balance two important things:

1. Releasing new features and making improvements.
2. Keeping the application reliable for customers.

If the team consumes its error budget too quickly, it may need to slow down risky releases and focus on fixing reliability issues.

This is one way SRE teams use SLOs to make practical engineering decisions.

6. What Is the Difference Between SLI, SLO, SLA and Error Budget?

Let's quickly revise the four terms we have covered.

Final Thoughts

When I first came across SLA, SLO and SLI, I found them confusing because the names sounded so similar.

But I realised that I was trying to remember the definitions without understanding the difference between them.

The exam marks example helped me understand the difference between an actual result and a target. The school bus example helped me understand what a formal promise or agreement means.

Once I connected these examples to applications, the technical concepts started making much more sense.

If there is just one thing I want you to take away from this article, it is this:

SLI measures. SLO targets. SLA promises.

You don't have to memorise complicated definitions to understand these concepts.

And the next time you hear someone talking about service reliability, you will know that measuring a service, setting a target for it, and making a promise to a customer are three different things.

Because building an application is important, but building an application that people can depend on is what reliability engineering is really about.