Alerts & Notifications

DOCS

Get notified immediately when something goes wrong. Configure multiple channels and control exactly when and how you're alerted.

Notification channels

HowlOps supports multiple notification channels. You can add as many channels as you need and assign different channels to different monitors.

Email

All plans

Send incident alerts to any email address. Available on every plan.

Required configuration

address

Recipient email

Generic webhook

Paid plans

POSTs the standard HowlOps JSON payload to any HTTPS endpoint on every incident event.

Required configuration

url

Webhook URL (HTTPS)

Slack

All plans

Post rich incident alerts (with Ack / Resolve / Silence buttons) to any Slack channel.

For OAuth setup, use the Slack card on the Integrations page.

Required configuration

url

Slack incoming-webhook URL: Create an incoming webhook at api.slack.com/apps → Incoming Webhooks.

Discord

All plans

Send notifications with interactive buttons to any Discord server channel.

Required configuration

webhook_url

Discord webhook URL: Server Settings → Integrations → Webhooks → New Webhook.

All plans

Forwards alerts via the HowlOps Telegram bot. Connect with one click from the Integrations page.

Easiest path: use the Telegram card on the Integrations page to deep-link the bot.

Required configuration

token (optional)

Bot token: Leave blank to use the platform-managed HowlOps bot.

chat_id

Chat ID

PagerDuty

Paid plans

Triggers and auto-resolves PagerDuty incidents via Events API v2 (Routing Key required).

Required configuration

routing_key

Integration Key (Routing Key): Services → your service → Integrations → Events API v2 → Integration Key.

Pushover

Paid plans

Push notifications to the Pushover mobile/desktop apps using your user key and application token.

Required configuration

user

User key: Visible on your Pushover dashboard at pushover.net.

token

Application token: Create an application at pushover.net/apps/build.

Opsgenie

Paid plans

Creates and auto-closes Opsgenie alerts. Use the EU region if your Opsgenie account is on the EU data centre.

Required configuration

api_key

Integration API key: Settings → API key management → Create API key.

region (optional)

Region

VictorOps / Splunk On-Call

Paid plans

Routes incidents through VictorOps generic integration. Needs both the API key from the integration and a routing key for the on-call team.

Required configuration

api_key

API Key: Settings → Integrations → REST Endpoint → API key.

routing_key

Routing Key: Alert routing key for the target on-call policy.

Mattermost

Paid plans

Posts alerts to a Mattermost channel via an incoming webhook (Slack-compatible payload).

Required configuration

webhook_url

Incoming webhook URL: Mattermost: Main Menu → Integrations → Incoming Webhooks.

Google Chat

Paid plans

Posts alerts to a Google Chat space via an incoming webhook.

Required configuration

webhook_url

Incoming webhook URL: Google Chat space → Apps & integrations → Webhooks → Add.

ntfy

Paid plans

Self-hostable pub/sub push. Alerts go to a topic on ntfy.sh or your own server.

Required configuration

server (optional)

Server URL: Leave blank for the public ntfy.sh, or point at your self-hosted server.

topic

Topic: The topic to publish to. Subscribe to it in the ntfy app.

token (optional)

Access token: Optional — only for protected topics (Bearer auth).

Gotify

Paid plans

Self-hosted push server. Alerts are delivered as Gotify messages.

Required configuration

server

Server URL

token

Application token: Gotify → Apps → create an application → copy its token.

Apprise

Paid plans

Self-hosted Apprise API — fans a single alert out to 110+ services (Slack, Telegram, SMS, etc.).

Required configuration

server

Apprise API URL

config_key (optional)

Config key: For persistent-config mode (/notify/{key}). Leave blank to use stateless URLs below.

urls (optional)

Apprise URLs: Stateless mode — comma-separated Apprise URLs.

Microsoft Teams

Paid plans

Posts Adaptive Card alerts to a Teams channel via an incoming webhook (legacy MessageCard fallback for outlook.office.com URLs).

Required configuration

webhook_url

Incoming webhook URL: Teams channel → Connectors → Incoming Webhook (or a Power Automate workflow webhook).

Jira

Paid plans

Creates a Jira issue for every new incident. Uses Atlassian Cloud REST API with basic auth (email + API token).

Required configuration

domain

Atlassian domain: The part before .atlassian.net (e.g. acme for acme.atlassian.net).

email

Account email

api_token

API token: Create at id.atlassian.com/manage-profile/security/api-tokens.

project_key

Project key: Short project identifier (e.g. OPS, INFRA).

issue_type (optional)

Issue type: Defaults to "Bug" when left blank.

Zendesk

Paid plans

Opens a Zendesk ticket for every new incident. Uses email/token basic auth against the Zendesk API.

Required configuration

subdomain

Subdomain: The part before .zendesk.com (e.g. acme for acme.zendesk.com).

email

Agent email

api_token

API token: Admin Center → Apps and integrations → Zendesk API → API token.

AWS SNS

Paid plans

Publishes incident messages to an AWS SNS topic using raw SigV4 signing. Pair with SNS subscriptions for SMS/email/SQS/HTTPS fan-out.

Required configuration

topic_arn

Topic ARN

region (optional)

AWS region

access_key_id

Access key ID

secret_access_key

Secret access key

SMS

Paid plans

Receive SMS alerts via the HowlOps Twilio account (platform admin manages credentials). Just enter the recipient phone in E.164 format.

SMS sending requires a platform admin to enable Twilio in Admin → Notification Providers.

Required configuration

to

Recipient phone (E.164): International format with leading "+", e.g. +14155550123.

Voice call

Paid plans

Receive a voice call on a verified phone number when an incident fires. The platform places the call through Twilio and reads the alert payload via TTS. Only verified numbers are dialable.

Verify the phone number under Settings → Notifications → Voice + phone verification. Backend test-send refuses unverified numbers as a safety guard.

Required configuration

phone_e164

Recipient phone (verified, E.164): Must be a phone number verified via Settings → Notifications → Verify phone.

Assigning channels to a monitor

Once you have added a channel, attach it to any monitor in three steps:

Open the monitor from the Monitors list and click Edit
Scroll to the Notifications section and select one or more channels from the dropdown
Click Save. Alerts for this monitor will now be sent to the selected channels.

You can assign the same channel to multiple monitors. Removing a channel from a monitor does not delete the channel itself; it stays available for other monitors.

Webhook payload

When using a custom webhook, HowlOps POSTs the following JSON to your endpoint:

{ "version": "1", "event": "monitor.down", "monitor_name": "Production API", "url": "https://api.example.com/health", "details": "HTTP 503 - Service Unavailable", "timestamp": "2026-04-22T13:45:30Z", "tenant_id": "550e8400-e29b-41d4-a716-446655440000", "monitor_id": "7c9e6679-7425-40de-944b-e07fc1f90ae7", "heartbeat_id": "" }

Event types

Event	When it fires
monitor.down	Monitor or heartbeat is unreachable / failed
monitor.up	Monitor or heartbeat recovers after an incident
monitor.ssl_expiry	SSL certificate is expiring within the configured threshold
test	Sent when you click Send Test Alert in channel settings

Heartbeat events use the same event types as HTTP/PING monitors. When the event originates from a heartbeat, heartbeat_id is populated and monitor_id is empty. For PING monitors, the url field contains ping://TARGET instead of an HTTP URL.

Verifying webhook signatures

Each request includes an X-HowlOps-Signature header, an HMAC-SHA256 hex digest of the raw request body, signed with your webhook secret. Verify it on your server to reject forged requests:

// Node.js example const crypto = require("crypto"); function verifySignature(body, secret, signature) { const expected = crypto .createHmac("sha256", secret) .update(body, "utf8") .digest("hex"); return crypto.timingSafeEqual( Buffer.from(expected), Buffer.from(signature) ); }

Alert sensitivity

Control when alerts fire with the alert threshold setting:

Threshold 2: Wait for 2 consecutive failures before alerting (default, reduces false alarms from transient blips)
Threshold 1: Alert on the first failure. Opt in for critical services where you want to be paged immediately.

Recovery alerts: You also receive a notification when your monitor recovers after an incident. Recovery alerts are on by default; you can opt out per channel.

Quiet hours are opt-in per monitor. Enable Respect quiet hours on each monitor to hold non-critical alerts during your quiet window. Alerts from external integrations (Alertmanager, webhooks) always respect quiet hours automatically. Critical alerts bypass quiet hours regardless of this setting.

Test your channels before relying on them for production alerts. Use the Send Test Alert button in each channel configuration.