Getting started with Honeycomb SLOs in Swamp

In this tutorial, we will connect a Swamp repository to a Honeycomb team. We will create an SLI derived column for a checkout dataset, then create a 99.9 percent SLO that uses it.

What we will build

First we pull the Honeycomb extension and store a Honeycomb Configuration Key in a vault. Then we create a behavior named checkout-slo for the checkout dataset and run two of its methods. The first creates a derived column that marks successful checkout requests. The second creates a 30-day SLO based on that column. When we finish, the derived column and the SLO exist in Honeycomb, and Swamp has a record of each one as data.

Prerequisites

Swamp installed and signed in with swamp auth login (see Install Swamp)
A terminal open in a new repository created with swamp repo init
A Honeycomb team in the US region with a dataset named checkout whose events have an http.status_code field
A Honeycomb v1 Configuration Key from your team settings

Pull the Honeycomb extension

First, we pull the extension that provides the Honeycomb behavior types:

swamp extension pull @hivemq/honeycomb

You will see output like:

INF extension·pull: Pulling "@hivemq/honeycomb"@"2026.10.01.1790870399"
INF extension·pull: Identity verified: "@hivemq/honeycomb"@"2026.10.01.1790870399"
INF extension·pull: Pulled "@hivemq/honeycomb"@"2026.10.01.1790870399"
INF extension·pull: Extracted 16 files:

Look at the behavior type

Next, we read the description of the @hivemq/honeycomb type:

swamp behavior type describe @hivemq/honeycomb --compact

The output looks like:

Type: @hivemq/honeycomb
Version: 2026.10.01.1

Global Arguments:
  configKey (string) *required
  region (string) [us, eu]
  datasetSlug (string) *required

Data Outputs:
  slo [resource]
  derivedColumn [resource]
  burnAlert [resource]
  query [resource]
  queryAnnotation [resource]
  trigger [resource]

Methods:
  sync - Fetch current SLO state from Honeycomb by SLO ID
    Inputs:
      sloId (string) *required
  updateSlo - Update SLO metadata (target, description, period, SLI). All fields are optional — only provided fields are changed. Pass `sliAlias` to repoint the SLO at a different derived column (the column must already exist; create it first via createDerivedColumn).
    Inputs:
      sloId (string) *required
      name (string)
      description (string)
      targetPercent (number)
      timePeriodDays (integer)
      sliAlias (string)
  createSlo - Create a new SLO in Honeycomb. Returns the assigned SLO ID.
    Inputs:
...

Notice the three global arguments: configKey, region and datasetSlug. The type requires configKey and datasetSlug. Notice also the createDerivedColumn and createSlo methods, which we will use shortly.

Keep the Configuration Key in a vault

The Configuration Key is a secret, so it goes in a vault and not in the behavior definition. We create a vault named honeycomb:

swamp vault create local_encryption honeycomb

You will see output like:

INF vault·create: Created vault: "honeycomb" ("Local Encryption")

Now we store the key under the name config-key. Replace the placeholder with your real Configuration Key:

swamp vault put honeycomb config-key hcxik_replace_with_your_configuration_key

This command encrypts the key and stores it in the honeycomb vault under the name config-key.

We check that the vault holds it:

swamp vault list-keys honeycomb

This command lists the key names in the honeycomb vault, which should include config-key, and does not show their values.

Create the behavior

Now we create a behavior for the checkout dataset in the us region. It reads the key from the vault:

swamp behavior create @hivemq/honeycomb checkout-slo \
    --global-arg "configKey=${{ vault.get('honeycomb', 'config-key') }}" \
    --global-arg region=us \
    --global-arg datasetSlug=checkout

You will see output like:

Created: checkout-slo (@hivemq/honeycomb)
Path: /tmp/.../models/@hivemq/honeycomb/checkout-slo.yaml
Version: 2026.10.01.1

Global Arguments:
  configKey (string) *required
  region (string) [us, eu]
  datasetSlug (string) *required

Methods:
  sync - Fetch current SLO state from Honeycomb by SLO ID
    Inputs:
      sloId (string) *required
  updateSlo - Update SLO metadata (target, description, period, SLI). All fields are optional — only provided fields are changed. Pass `sliAlias` to repoint the SLO at a different derived column (the column must already exist; create it first via createDerivedColumn).
    Inputs:
      sloId (string) *required
      name (string)
      description (string)
      targetPercent (number)
      timePeriodDays (integer)
      sliAlias (string)
  createSlo - Create a new SLO in Honeycomb. Returns the assigned SLO ID.
    Inputs:
      name (string) *required
      sliAlias (string) *required
      targetPercent (number) *required
      timePeriodDays (integer) *required
      description (string)
      datasetSlugs (array)
  createDerivedColumn - Create a new derived column (SLI calculated field) in the target dataset.
...

We validate the definition before calling Honeycomb:

swamp behavior validate checkout-slo

The output looks like:

Validating: checkout-slo (@hivemq/honeycomb)
  ✓ Definition schema
  ✓ Type version
  ✓ Global arguments
  ✓ Method arguments
  ✓ Expression paths
  ✓ Check selection
Summary: 6/6 validations passed
Result: PASSED

Create the SLI derived column

The SLO needs a derived column that is true for each good event. We count a checkout request as good when its status code is below 500:

swamp behavior run checkout-slo createDerivedColumn \
    --input alias=sli.checkout_success \
    --input 'expression=IF(EXISTS($http.status_code), LT($http.status_code, 500))' \
    --input 'description=Checkout requests that did not return a server error'

This command creates the sli.checkout_success derived column in the checkout dataset in Honeycomb and writes a derivedColumn resource in Swamp.

Create the SLO

Now we create a 30-day SLO with a 99.9 percent target. It refers to the derived column by its alias:

swamp behavior run checkout-slo createSlo \
    --input 'name=Checkout availability' \
    --input sliAlias=sli.checkout_success \
    --input 'targetPercent:json=99.9' \
    --input 'timePeriodDays:json=30' \
    --input 'description=Checkout requests succeed 99.9 percent of the time'

This command creates the SLO in Honeycomb and writes an slo resource that holds the SLO ID Honeycomb assigned. In Honeycomb, the SLO list now includes Checkout availability.

Look at the data

We list the resources that the two runs wrote:

swamp data query --limit 10

This command lists the most recent data records in the repository, including the derivedColumn and slo resources from checkout-slo. Make a note of the SLO ID in the slo resource. You will need it to attach burn rate alerts later.

Look at the behavior

Finally, we look at the finished behavior:

swamp behavior get checkout-slo

You will see output like:

Name: checkout-slo (@hivemq/honeycomb)
ID: 08343f33-58af-474d-8163-7d80cc5030fa
Version: 1

Global Arguments:
  configKey: ***
  region: us
  datasetSlug: checkout

Type Version: 2026.10.01.1

Global Arguments Schema:
  configKey (string) *required
  region (string) [us, eu]
  datasetSlug (string) *required

Methods:
  sync - Fetch current SLO state from Honeycomb by SLO ID
    Inputs:
      sloId (string) *required
  updateSlo - Update SLO metadata (target, description, period, SLI). All fields are optional — only provided fields are changed. Pass `sliAlias` to repoint the SLO at a different derived column (the column must already exist; create it first via createDerivedColumn).
    Inputs:
      sloId (string) *required
      name (string)
      description (string)
      targetPercent (number)
      timePeriodDays (integer)
      sliAlias (string)
  createSlo - Create a new SLO in Honeycomb. Returns the assigned SLO ID.
    Inputs:
...

Notice that configKey is stored as the vault.get() expression, not as the key itself.

What we built

We pulled the Honeycomb extension, stored a Configuration Key in its own vault and created a behavior for the checkout dataset. We used that behavior to create an SLI derived column and a 99.9 percent SLO in Honeycomb, then found the derivedColumn and slo resources in Swamp data. Understanding Honeycomb automation in Swamp explains why the SLI and the SLO are separate objects.

GETTING STARTED WITH HONEYCOMB SLOS IN SWAMP

What we will build

Prerequisites

Pull the Honeycomb extension

Look at the behavior type

Keep the Configuration Key in a vault

Create the behavior

Create the SLI derived column

Create the SLO

Look at the data

Look at the behavior

What we built