Tags

​

Model

​

What you can tag

• Surfaces it in tag-filtered dashboard views.
• Feeds into notification policy match conditions for alert routing.
• Allows tag-based filtering on incident list endpoints.

​

Common tagging strategies

​

Routing alerts by tag

notification-policies:
  - name: Payments tier-1 → PagerDuty
    match:
      tags: [team-payments, tier-1]
    channels: [pagerduty-payments]
    escalation: tier-1-rotation

​

Managing tags

devhelm tags list
devhelm tags create --name payments --color "#10b981"
devhelm tags update <tag-id> --color "#f59e0b"
devhelm tags delete <tag-id>

tags:
  - name: payments
    color: "#10b981"
  - name: tier-1
    color: "#ef4444"

monitors:
  - name: Stripe Charge API
    type: HTTP
    tags: [payments, tier-1]
    config:
      url: https://api.stripe.com/v1/charges

resource "devhelm_tag" "payments" {
  name  = "payments"
  color = "#10b981"
}

resource "devhelm_monitor" "stripe" {
  name              = "Stripe Charge API"
  type              = "HTTP"
  frequency_seconds = 60
  tag_ids           = [devhelm_tag.payments.id]
  config            = jsonencode({ url = "https://api.stripe.com/v1/charges" })
}

​

Lifecycle and constraints

• Renaming a tag updates references everywhere automatically — UUIDs stay stable.
• Deleting a tag removes it from every monitor it’s attached to. Notification policy match conditions referencing the deleted tag are flagged as broken in the dashboard until edited.
• Tag names are unique within the organization. Two tags with the same name cannot coexist.
• Tags are organization-scoped. They are visible across all workspaces in the organization.

​

Reporting and filtering

• Filter list views by tag combinations on monitors and incidents in the dashboard.
• Audit log search can filter by subject.tags for tag-scoped activity reviews.
• REST API supports tag and tags query params on monitor and incident list endpoints — useful for building custom dashboards or feeding tag-filtered data into BI tools.

​

Next steps