Service Level Objectives as Code: Terraforming Honeycomb SLOs

In March, we announced official support for a Honeycomb Terraform Provider. Today, we’re announcing additional support for managing Honeycomb Service Level Objectives (SLOs) with Terraform. This furthers Honeycomb’s support for configuration as code and it gives you programmatic control for an immensely popular Honeycomb feature.

Rounding out the Honeycomb Management API

In 2021, we released the Honeycomb Management API. During the beta period, a community-created Terraform provider for Honeycomb was created. While that new provider has proved useful to many customers, it didn’t have support for managing Honeycomb SLOs; because there was no SLO Management API.

Since then, we’ve adopted the Honeycomb Terraform Provider. In May, we opened up the new SLO and Burn Alerts API endpoints to the public. Today, we released version 0.7.0 of the Honeycomb Terraform Provider with support for creating and managing Honeycomb SLOs as code with the new honeycombio_sloandhoneycombio_burn_alertresources.

The addition of the SLO and Burn Alert endpoints helps round out the existing set of Management APIs that collectively enable programmatic workflows to manage objects found in the Honeycomb UI. Now you can seamlessly manage your SLO configurations in code and apply best practices like version control and peer review to their lifecycle.

Managing SLOs with Terraform

The Honeycomb Management API is available to all Honeycomb users. As of April, Honeycomb SLOs are now available to both Pro and Enterprise users. In case you’re new to Honeycomb SLOs, you should check out this primer to better understand why they’re the preferred way to create reliable and actionable alerts while also reducing alert fatigue.

With the new SLO and Burn Alert resources in the Honeycomb Terraform Provider you can now manage your services’ Service Level Indicators (SLIs), SLOs, and error budget alerting via the Terraform configurations and workflow you use to programmatically manage the other critical components of your business.

Honeycomb SLOs rely on SLIs to collect data around service health. In Honeycomb, SLIs are set up as a derived column. To configure an SLO, you should:

• Create a derived column to surface conditions you care about
• Create an SLO and configure it to use the above derived column as its SLI
• Create a Burn Alert that tells you when the error budget for the above SLO will be exhausted

As an example, your Terraform code could look something like this:

resource "honeycombio_derived_column" "sli-example" {
  alias       = "sli.example"
  description = "SLI: request latency less than 400ms"
  dataset     = var.dataset
  expression  = <<EOF
IF(
  NOT(EXISTS($trace.parent_id)),
  LT($duration_ms, 400)
)
EOF
}

resource "honeycombio_slo" "example" {
  name              = "Request Latency"
  description       = "Total latency should be less than 400ms"
  sli               = honeycombio_derived_column.sli-example.alias
  dataset           = var.dataset
  target_percentage = 99.95
  time_period       = 30
}

resource "honeycombio_burn_alert" "example" {
  dataset            = var.dataset
  slo_id             = honeycombio_slo.example.id
  exhaustion_minutes = 240 # 4 hours

  recipient {
    type   = "slack"
    target = "#slo-alerts"
  }
}

That’s all it takes! Now with your SLOs codified using Terraform you’re able to easily define, measure, validate, and adjust engineering priorities based on what matters most to your business.

Try it for yourself

The Honeycomb Terraform Provider is now available in the Terraform Registry. You can read more about Honeycomb SLOs in our documentation and more about the Honeycomb Terraform provider in the provider’s documentation. If you don’t have a Honeycomb account, check out our free tier to get started! 

If you try this new feature, be sure to share feedback in our  Pollinators Slack Community to let us know what you think! You can find us in the #discuss-slo and #discuss-terraform-provider channels, which are dedicated to these topics.