——— SLO Studio
Predictable Softwares
are Predictable
💵
As a product owner, it’s a nightmare to have users complain about the product on social media. We get paid to make sure that these complaints marginalize over time. We may not eradicate them but can certainly reduce them.
We don’t want just the complaining users to reduce. We like the happy customers to increase.
Service Level Objectives are an industrially accepted way of measuring software behavior to prevent bad customer experiences.
——— SLO Studio
Predictable Softwares
are Predictable
💵
As a product owner, it’s a nightmare to have users complain about the product on social media. We get paid to make sure that these complaints marginalize over time. We may not eradicate them but can certainly reduce them.
We don’t want just the complaining users to reduce. We like the happy customers to increase.
Service Level Objectives are an industrially accepted way of measuring software behavior to prevent bad customer experiences.
——— SLO Studio
Predictable Softwares
are Predictable
💵
As a product owner, it’s a nightmare to have users complain about the product on social media. We get paid to make sure that these complaints marginalize over time. We may not eradicate them but can certainly reduce them.
We don’t want just the complaining users to reduce. We like the happy customers to increase.
Service Level Objectives are an industrially accepted way of measuring software behavior to prevent bad customer experiences.
Last9’s latest improvement is an SLO Studio
So far, Last9 offered SLOs only for customer-facing HTTP services. But, with SLO Studio, you can now set objectives on any service, any number of times. 🙂
Improving Reliability in 3 Simple Steps
“A thing that you don’t measure cannot be improved”
1
First, find the weakest parts of the system
2
Then, fix them and ensure that the leakages are fixed
3
Finally, prevent the leakage from happening elsewhere
But, how do you quickly identify the vulnerable parts?
Last9’s latest improvement is an SLO Studio
So far, Last9 offered SLOs only for customer-facing HTTP services. But, with SLO Studio, you can now set objectives on any service, any number of times. 🙂
Improving Reliability in 3 Simple Steps
“A thing that you don’t measure cannot be improved”
1
First, find the weakest parts of the system
2
Then, fix them and ensure that the leakages are fixed
3
Finally, prevent the leakage from happening elsewhere
But, how do you quickly identify the vulnerable parts?
When you land at the Service Health Dashboard, the services with the most recent dots being green are working well, but the ones in red are in trouble.
In the absence of SLOs, you have no quick way of prioritization. Instead, you will have to inspect each service’s health history and classify it as urgent, important, or ignorable.
Once you have a framework to sieve the urgent from the rest, you can prioritize better.
Example: In the screenshot aside —
RDS
should be our immediate priority 🚨
Terraform
does not have any objectives set on it ⚠
last9api
is performing well 👍
RDS as a service is in trouble, whereas last9api is primarily good while terraform services does not have SLO set.
When you land at the Service Health Dashboard, the services with the most recent dots being green are working well, but the ones in red are in trouble.
In the absence of SLOs, you have no quick way of prioritization. Instead, you will have to inspect each service’s health history and classify it as urgent, important, or ignorable.
Once you have a framework to sieve the urgent from the rest, you can prioritize better.
Example: In the screenshot aside —
RDS
should be our immediate priority 🚨
Terraform
does not have any objectives set on it ⚠
last9api
is performing well 👍
RDS as a service is in trouble, whereas last9api is primarily good while terraform services does not have SLO set.
SLOs Eased
You can either love running or hate running, but you will definitely love this analogy — take a fresh look at SLOs!

Read on our blog →

While using last9
Whenever you see things like this, you are yet to set an objective for that service.
The Service Health Dashboard shows grey dots when an SLO is not set.
The Service Map header calls for an action when an SLO is not set.
Service Level Indicators
Once you have an agreed objective that a service must serve, Last9 provides all the tools to maintain and enforce them on services.
Start by choosing the rightful Service Level Indicator that needs to be measured.
How are they different from Metrics?
Service Level Indicators are expressions that can combine or transform one or more metrics available on the Service.
Last9 has a catalog that defines Key SLIs for all frequently used Components and Services. This is how you find them:
How can I add custom SLIs?
Coming soon. :)
Once you have an agreed objective that a service must serve, Last9 provides all the tools to maintain and enforce them on services.
Start by choosing the rightful Service Level Indicator that needs to be measured.
How are they different from Metrics?
Service Level Indicators are expressions that can combine or transform one or more metrics available on the Service.
Last9 has a catalog that defines Key SLIs for all frequently used Components and Services. This is how you find them:
How can I add custom SLIs?
Coming soon. :)
While using last9
You can find the available SLIs by clicking on the details for any node.
Click the info icon to open the sidebar
Sidebar lists the SLI overview details for all nodes
Click the info icon to open the sidebar
Sidebar lists the SLI overview details for all nodes
Window or Request-based SLOs
Choosing the right kind of SLO improves the quality of alerts and represents a more accurate customer-side perception of the service’s performance!
Here’s a general framework/guide to follow that helps you choose one:
✌ Window Based
Service with extremely low throughput
If the service has extremely low throughput, you should prefer Window-based SLOs.
When there is less throughput, you have a tiny disposable budget. Therefore, it is essential to serve every request while the system is up.
Service & Availability at Scale
If the service is expected to behave the same, regardless of the scale it operates under; you should prefer Window-based SLOs.
Example:
A get-balance service should return the active balance before a transaction. It doesn’t matter whether you send a single request or 100. If it fails, it is considered degraded.
Service with extremely low throughput
If the service has extremely low throughput, you should prefer Window-based SLOs.
When there is less throughput, you have a tiny disposable budget. Therefore, it is essential to serve every request while the system is up.
Service & Availability at Scale
If the service is expected to behave the same, regardless of the scale it operates under; you should prefer Window-based SLOs.
Example:
A get-balance service should return the active balance before a transaction. It doesn’t matter whether you send a single request or 100. If it fails, it is considered degraded.
Service without Replications
If the service doesn’t have multi-zone highly replicated deployment, you should prefer Window-based SLOs.
The chances of all requests failing together are relatively large. This is because the underlying fault will impact almost 100% of the requests for the duration of the fault.
Service = Infrastructure Service
If the service is an Infrastructure Service like Database, Cache, Load Balancer, etc., it is assumed that they are operational for 100% of the duration. Therefore, it is advised to use Window-based SLOs here.
Service without Replications
If the service doesn’t have multi-zone highly replicated deployment, you should prefer Window-based SLOs.
The chances of all requests failing together are relatively large. This is because the underlying fault will impact almost 100% of the requests for the duration of the fault.
Service = Infrastructure Service
If the service is an Infrastructure Service like Database, Cache, Load Balancer, etc., it is assumed that they are operational for 100% of the duration. Therefore, it is advised to use Window-based SLOs here.
✋ Request Based
Service is Internal
If the service is internal and doesn’t face the user — Use Request-based SLOs.
The caller system often retries a failed request and has a concept of circuit-breaking the upstream based on the number of requests and not how long the upstream is unavailable
Example:
If your favorite payment provider fails for 50% of the requests (and not for x-hours a day), you will switch to an alternate.
Service has Requests
If the service has a notion of a request, you pick request based SLOs.
Service is Internal
If the service is internal and doesn’t face the user — Use Request-based SLOs.
The caller system often retries a failed request and has a concept of circuit-breaking the upstream based on the number of requests and not how long the upstream is unavailable
Example:
If your favorite payment provider fails for 50% of the requests (and not for x-hours a day), you will switch to an alternate.
Service has Requests
If the service has a notion of a request, you pick request based SLOs.
While using last9
In Last9, you can now easily choose the type of the SLO while creating it.

Head to Service Settings → Service Level Objectives

Happy SLO Fast Services!

Last9’s latest improvement is an SLO Studio
So far, Last9 offered SLOs only for customer-facing HTTP services. But, with SLO Studio, you can now set objectives on any service, any number of times. 🙂
Improving Reliability in 3 Simple Steps
“A thing that you don’t measure cannot be improved”
1
First, find the weakest parts of the system
2
Then, fix them and ensure that the leakages are fixed
3
Finally, prevent the leakage from happening elsewhere
But, how do you quickly identify the vulnerable parts?
When you land at the Service Health Dashboard, the services with the most recent dots being green are working well, but the ones in red are in trouble.
In the absence of SLOs, you have no quick way of prioritization. Instead, you will have to inspect each service’s health history and classify it as urgent, important, or ignorable.
Once you have a framework to sieve the urgent from the rest, you can prioritize better.
Example: In the screenshot aside —
RDS
should be our immediate priority 🚨
Terraform
does not have any objectives set on it ⚠
last9api
is performing well 👍
RDS as a service is in trouble, whereas last9api is primarily good while terraform services does not have SLO set.
SLOs Eased
You can either love running or hate running, but you will definitely love this analogy — take a fresh look at SLOs!

Read on our blog →

While using last9
Whenever you see things like this, you are yet to set an objective for that service.
The Service Health Dashboard shows grey dots when an SLO is not set.
The Service Map header calls for an action when an SLO is not set.
Service Level Indicators
Once you have an agreed objective that a service must serve, Last9 provides all the tools to maintain and enforce them on services.
Start by choosing the rightful Service Level Indicator that needs to be measured.
How are they different from Metrics?
Service Level Indicators are expressions that can combine or transform one or more metrics available on the Service.
Last9 has a catalog that defines Key SLIs for all frequently used Components and Services. This is how you find them:
How can I add custom SLIs?
Coming soon. :)
While using last9
You can find the available SLIs by clicking on the details for any node.
Click the info icon to open the sidebar
Sidebar lists the SLI overview details for all nodes
Window or Request-based SLOs
Choosing the right kind of SLO improves the quality of alerts and represents a more accurate customer-side perception of the service’s performance!
Here’s a general framework/guide to follow that helps you choose one:
✌ Window Based
Service with extremely low throughput
If the service has extremely low throughput, you should prefer Window-based SLOs.
When there is less throughput, you have a tiny disposable budget. Therefore, it is essential to serve every request while the system is up.
Service & Availability at Scale
If the service is expected to behave the same, regardless of the scale it operates under; you should prefer Window-based SLOs.
Example:
A get-balance service should return the active balance before a transaction. It doesn’t matter whether you send a single request or 100. If it fails, it is considered degraded.
Service without Replications
If the service doesn’t have multi-zone highly replicated deployment, you should prefer Window-based SLOs.
The chances of all requests failing together are relatively large. This is because the underlying fault will impact almost 100% of the requests for the duration of the fault.
Service = Infrastructure Service
If the service is an Infrastructure Service like Database, Cache, Load Balancer, etc., it is assumed that they are operational for 100% of the duration. Therefore, it is advised to use Window-based SLOs here.
✋ Request Based
Service is Internal
If the service is internal and doesn’t face the user — Use Request-based SLOs.
The caller system often retries a failed request and has a concept of circuit-breaking the upstream based on the number of requests and not how long the upstream is unavailable
Example:
If your favorite payment provider fails for 50% of the requests (and not for x-hours a day), you will switch to an alternate.
Service has Requests
If the service has a notion of a request, you pick request based SLOs.
While using last9
In Last9, you can now easily choose the type of the SLO while creating it.

Head to Service Settings → Service Level Objectives

Happy SLO Fast Services!

Reliability Engineering with Last9 is incredibly
easy. But don’t just take our word for it.
Reliability Engineering with Last9 is incredibly
easy. But don’t just take our word for it.
Reliability Engineering with Last9 is incredibly
easy. But don’t just take our word for it.
Make running systems at scale, fun and embarrassingly easy.
backed by
Make running systems at scale, fun and embarrassingly easy.
backed by
Make running systems at scale, fun and embarrassingly easy.
backed by
Join the Last9 User Group
Drop in to learn about Reliability, SRE, how our community uses Last9’s platform; and help us shape the future of Last9.
Open Discord
Last9 cares deeply about its customer’s data and is SOC2 Type1 certified. Please contact us at hello@last9.io for the report.
Join the Last9 User Group
Drop in to learn about Reliability, SRE, how our community uses Last9’s platform; and help us shape the future of Last9.
Open Discord
Last9 cares deeply about its customer’s data and is SOC2 Type1 certified. Please contact us at hello@last9.io for the report.
Join the Last9 User Group
Drop in to learn about Reliability, SRE, how our community uses Last9’s platform; and help us shape the future of Last9.
Open Discord
Last9 cares deeply about its customer’s data and is SOC2 Type1 certified. Please contact us at hello@last9.io for the report.