We recommend that you follow certain best practices when using Service Level Objectives (SLOs).
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.
Honeycomb limits you to attaching only one SLO to any SLI Derived Column. For example, you may not have both a 30-day and a 60-day SLO attached to the same SLI column, although you may have as many Burn Alerts attached to an SLO as you wish.
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.
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.
Honeycomb limits you to 30 SLOs per dataset.
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.
