> ## Documentation Index > Fetch the complete documentation index at: https://docs.chronosphere.io/llms.txt > Use this file to discover all available pages before exploring further. # Service level objectives export const ServiceNavIcon = props => { return ; }; It's critical to understand your services' performance and reliability to ensure those services are meeting your business's needs. To do so, you can define and communicate your expectations for a service's performance. In many cases, it's sufficient to define [monitors](/investigate/alerts) that measure metrics about a service against a fixed threshold, and to alert those responsible for the service when that threshold is exceeded. However, in complex and dynamic systems monitors can also be falsely triggered by inconsistent data or fail to alert on gradual issues that build up over time. *Service level objectives* (SLOs) instead focus on longer-term performance reporting and changes in error rates. In an SLO, you define these elements: * A percentile *objective* that represents your goal for uptime or error-free operation. For example, your objective for a service might be to maintain 99.95% uptime. * An *error budget*, or your tolerance for downtime or errors. This is the inverse of your objective, because it represents the service capacity that can be lost before the service fails its objective. Likewise, changes to your objective also change your error budget. For example, a 99.95% uptime objective also defines a 0.05% error budget. * Metrics queries that define *indicators* of your performance against that objective. For example, you might query for the summed duration of error responses that your service returned to requests, and compare that to the total time the service was running. This creates an *error ratio*, or the percentage of errors against your total. * A *time window* that you'll measure for performance against your objective. Your SLO measures your error or success rates against the total over the time window, such as the last four weeks, to determine whether the service met the objective. Chronosphere Observability Platform lets you create SLOs you can use to define objectives, set queries, and measure and visualize performance over a time window. Chronosphere SLOs use a rolling time window to report the ongoing status of a service, as opposed to calendar time windows that are fixed to specific dates. After you've defined your SLO, it then identifies your error or success rate against the total over the time window. If the service met your objective in the time window, the SLO reports the service is healthy. If not, the SLO reports its objective was breached and visualizes the state of metrics before the breach for investigation. For a high-level overview of planning and designing SLOs, see [Design service level objectives](/administer/design-slos). For instructions on how to create, update, and delete an SLO, see [Manage service level objectives](/investigate/alerts/manage-slos). ## Differences from monitors Although SLOs seem similar to monitors, SLOs provide a more dynamic incident detection method that let you trigger alerts based on changes in real user experiences, rather than at an arbitrary threshold. SLOs also provide additional details for more granular notifications: * SLOs report the *burn rate* of your error budget, which you can configure to raise alerts when the service is depleting its error budget over a short period within your time window. Burn rate alerts can help you respond to sudden degradations of performance before they breach your SLO, and burn rate visualizations can identify patterns in error rates that might not be as evident when looking only at the service's metrics. For example, a burn rate alert can trigger notifications if more than 2% of your error budget is consumed over a one-hour span. You can then respond closer to the beginning of the incident and attempt to prevent the SLO from breaching by investigating the problem and finding a solution. Such a spike in burn rate will also be displayed on the SLO's burn rate chart, which can help you pinpoint when the service degradation started. * You can define label-based *dimensions* to break down your SLO's measurement by time series. This helps you respond to complex services represented by multiple time series by letting you signal for specific series that breach the SLO. * You can perform [differential diagnosis](/investigate/analyze/differential-diagnosis/metrics) (DDx) on your SLO's charts to begin correlating concerning patterns in error rates. ## SLO terminology Service performance is generally defined in these ways: * Service level agreements (SLA): Contracts between a provider and a client that determine acceptable performance measurements, and the consequences for violating those measurements. An SLA defines the limits and consequences for failures. * Service level objectives (SLO): Usually internal targets for specific metrics that the provider aims to meet. These should be as specific as possible and are usually stricter than the SLA. For example, to ensure you meet an SLA to maintain 99.95% uptime or respond to an incident in less than two hours, you might define your SLO as meeting a standard of 99.999% uptime or responding to an incident within 60 minutes. * Service level indicators (SLI): The measurement being evaluated in an SLO or SLA, often as service uptime, availability, or response success rate. For example, if a SLO is to maintain 99.999% service uptime, the SLI is the service's uptime metric. For more information about industry-standard SLO terminology, see the [Google SRE handbook](https://sre.google/sre-book/service-level-objectives/) and [Design service level objectives](/administer/design-slos). ## Use SLO metrics SLOs are powered by metrics that Observability Platform automatically creates based on your SLO definition. For a list of these metrics, see the [metrics dictionary](/overview/concepts/dictionary).