Best Practices for Service Level Objectives (SLOs)

Ent Pro We recommend that you follow certain best practices when using Service Level Objectives (SLOs).

​

Use SLOs across multiple datasets only when necessary

Even though Honeycomb allows you to create an SLO that shares a budget across multiple datasets/services, most SLOs can be made with one service/dataset. In most cases, you can define the correct SLO for an experience by putting the SLO on the service that is closest to your end users, which is also known as the edge service. Define an SLO across multiple services only when multiple edge services exist.

​

Attach only one SLO to any SLI

Honeycomb limits you to attaching only one SLO to any SLI Calculated Field. For example, you may not have both a 30-day and a 60-day SLO attached to the same SLI calculated field, although you may have as many Burn Alerts attached to an SLO as you wish.

​

Use SLOs with a reasonably high volume of data

SLOs are most effective when you have a reasonably high volume of data: a small number of failures in an hour should not make a major dent in your reliability.

​

Apply fairly few SLOs to any dataset

SLOs should describe interfaces to a system rather than, for example, customers. In this example, generally, customers should behave roughly similar to one another; if groups of customers have properties that set them apart from others, try to write SLOs against those properties instead.

​

Keep your retention period in mind

Honeycomb will track SLO values past your retention period, but will display these for only the Budget Burndown and Historical Compliance graphs. You cannot use BubbleUp or the heatmap to look at times beyond your retention period.