Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt

Use this file to discover all available pages before exploring further.

By the end of this guide, you’ll have separate monitoring configurations for staging and production, with shared base definitions and environment-specific overrides.

​
Strategy: separate files

The simplest approach is one YAML file per environment: 
repo/
├── devhelm.yml              # Production
├── devhelm.staging.yml      # Staging
└── .github/workflows/
    └── devhelm-deploy.yml

​
Production config

version: "1"

tags:
  - name: production
    color: "#ef4444"

monitors:
  - name: API Health
    type: HTTP
    config:
      url: https://api.example.com/health
    frequencySeconds: 30
    regions:
      - us-east
      - eu-west
      - ap-south
    tags: [production]
    assertions:
      - config:
          type: status_code
          expected: "200"
          operator: equals
        severity: fail
      - config:
          type: response_time
          thresholdMs: 1000
        severity: fail

alertChannels:
  - name: Production Slack
    config:
      channelType: slack
      webhookUrl: ${SLACK_WEBHOOK_PRODUCTION}

  - name: PagerDuty On-Call
    config:
      channelType: pagerduty
      routingKey: ${PAGERDUTY_ROUTING_KEY}

​
Staging config

Staging typically has longer intervals, fewer regions, and less aggressive alerting: 
version: "1"

tags:
  - name: staging
    color: "#f59e0b"

monitors:
  - name: API Health (Staging)
    type: HTTP
    config:
      url: https://api.staging.example.com/health
    frequencySeconds: 300
    regions:
      - us-east
    tags: [staging]
    assertions:
      - config:
          type: status_code
          expected: "200"
          operator: equals
        severity: fail

alertChannels:
  - name: Staging Slack
    config:
      channelType: slack
      webhookUrl: ${SLACK_WEBHOOK_STAGING}
Key differences from production:
AspectProductionStaging
Frequency30s300s (5 min)
Regions31
Response time assertionYes (1000ms)No
PagerDutyYesNo
Alert channelProduction Slack + PagerDutyStaging Slack only

​
Deploy with environment-specific tokens

Each environment uses its own API token: 
name: Deploy Monitoring
on:
  push:
    branches: [main]
    paths: ['devhelm.yml', 'devhelm.staging.yml']

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - uses: devhelmhq/setup-devhelm@v1
        with:
          api-token: ${{ secrets.DEVHELM_API_TOKEN_STAGING }}
      - run: devhelm validate devhelm.staging.yml
      - run: devhelm deploy -f devhelm.staging.yml --yes

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: devhelmhq/setup-devhelm@v1
        with:
          api-token: ${{ secrets.DEVHELM_API_TOKEN }}
      - run: devhelm validate devhelm.yml
      - run: devhelm deploy -f devhelm.yml --yes
Staging deploys first. Production only deploys if staging succeeds.

​
Secret management

Each environment needs its own secrets: 
# Production
devhelm secrets set SLACK_WEBHOOK_PRODUCTION=https://hooks.slack.com/...
devhelm secrets set PAGERDUTY_ROUTING_KEY=your-routing-key

# Staging (switch context or use a different token)
DEVHELM_API_TOKEN=$STAGING_TOKEN devhelm secrets set SLACK_WEBHOOK_STAGING=https://hooks.slack.com/...
Never share API tokens between environments. Use separate tokens so staging changes can’t accidentally affect production.

​
Next steps

CI/CD pipeline

Full GitHub Actions deployment workflow.

Monitoring as Code tutorial

YAML format and deploy workflow.

Migrating from Dashboard

Move existing monitors to config files.