Skip to main content
Alert channels define the destinations for incident notifications. Each channel type has its own delivery behavior, configuration, and plan requirements.
Define this in code. Manage alert channels as part of your monitoring-as-code workflow: YAML format · Terraform · CI/CD patterns

Channel types

TypeConfigurationPlan
EmailRecipient email addressesFree
SlackIncoming webhook URLStarter
DiscordWebhook URLStarter
WebhookURL + optional HMAC signing secretStarter
PagerDutyEvents API v2 routing keyPro
OpsGenieAPI keyPro
Microsoft TeamsWebhook URLPro

Lifecycle behavior

Channels fall into two notification models:

Fire-and-forget

Email, Slack, Discord, Teams, Webhook Each message is self-contained. The channel sends a notification when an incident is created and a separate notification when it’s resolved. There is no state maintained in the external system.

Trigger-resolve

PagerDuty, OpsGenie The channel opens an alert in the external system when an incident is created and explicitly resolves it when the incident resolves. The external system maintains its own state (acknowledgment, escalation, on-call routing) tied to the DevHelm incident. This distinction matters for escalation chain behavior — stateful integrations always close their external alerts on resolution, even when onResolve is set to silent.

Creating a channel

devhelm alert-channels create \
  --name "Engineering Slack" \
  --type slack \
  --webhook-url "https://hooks.slack.com/services/T.../B.../xxx"

Configuration by type

FieldDescription
recipientsArray of email addresses
FieldDescription
webhookUrlSlack incoming webhook URL
See Slack integration for setup instructions.
FieldDescription
webhookUrlDiscord webhook URL
See Discord integration for setup instructions.
FieldDescription
urlTarget URL that receives POST payloads
signingSecretOptional HMAC-SHA256 signing secret for payload verification
See Webhooks integration for payload format and verification.
FieldDescription
routingKeyPagerDuty Events API v2 routing key
See PagerDuty integration for setup instructions.
FieldDescription
apiKeyOpsGenie API key
See OpsGenie integration for setup instructions.
FieldDescription
webhookUrlTeams incoming webhook URL
See Teams integration for setup instructions.

Testing a channel

Verify your configuration before using it in a notification policy:
devhelm alert-channels test \
  --name "Test Slack" \
  --type slack \
  --webhook-url "https://hooks.slack.com/services/T.../B.../xxx"
The test endpoint sends a sample notification and reports whether delivery succeeded.

Delivery history

Track delivery attempts and failures for a channel:
curl https://api.devhelm.io/api/v1/alert-channels/<channel-id>/deliveries \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN"
Each delivery record includes the timestamp, target incident, HTTP status, and any error message.

Channel fields

FieldTypeDescription
idUUIDUnique channel identifier
namestringHuman-readable name
channelTypestringIntegration type
displayConfigobjectNon-sensitive configuration metadata
configHashstringSHA-256 hash of the full config (for change detection)
lastDeliveryAtdatetimeMost recent delivery attempt
lastDeliveryStatusstringResult of the last delivery (e.g., SUCCESS, FAILED)
Channel configurations are write-only for security. After creation, the API returns displayConfig (non-sensitive metadata) and configHash but never the full secret values.

Next steps

Notification policies

Route incidents to the right channels based on rules.

Integrations

Step-by-step setup for each integration.

Alerting guide

End-to-end guide for setting up alerting.