Glossary
SLO (Service Level Objective)
A Service Level Objective (SLO) is an internal reliability target that a team commits to maintaining, such as 99.9% uptime or a 95th-percentile response time below 300 ms.
General definition
SLO stands for Service Level Objective. It is the internal, engineering-owned target that sits between a vague aspiration (“we want to be reliable”) and the legally binding commitment of an SLA. SLOs are typically tighter than SLAs: if the SLA requires 99.9% uptime, the engineering team might set an SLO of 99.95% to give a buffer before the contractual obligation is breached.
- Availability SLO: percentage of time the service responds successfully
- Latency SLO: the Nth percentile response time (e.g. p95 or p99) must stay below a threshold
- Error-rate SLO: the percentage of requests returning 5xx errors must stay below a ceiling
- Throughput SLO: the system must sustain at least N messages per second under peak load
SLOs are measured against a time window (typically 30 days rolling) and consume from an “error budget”: if 0.1% of the month can fail, that is the budget. When the budget is used up, teams freeze risky changes and prioritise reliability work. This approach was popularised by Google’s Site Reliability Engineering (SRE) model.
In the Ethora ecosystem
On a cloud-hosted Ethora plan, SLOs are set and owned by the provider’s engineering team. They are the internal targets that back the publicly stated SLA. Customers see the SLA commitment; the SLO that sits behind it is the provider’s operational concern.
With a dedicated or self-hosted chat server, you define your own SLOs to match your regulatory and product requirements. For a healthcare messaging deployment, an SLO might specify that message delivery must succeed within two seconds for 99% of requests, and the team monitors against that target. Ethora’s support tiers include help designing and monitoring SLOs for dedicated environments. Regulated buyers can cite internally-owned SLOs in compliance documentation rather than relying solely on a vendor’s published SLA. Contact the team to discuss.
