Notification Channels — Slack, Email, PagerDuty, Webhooks — MonPG Docs

MonPG sends to four kinds of channel: Slack, email, PagerDuty, and a generic webhook. You configure them once at the org level and rules pick which ones to use.

Slack

Create an incoming webhook in your Slack workspace, paste the URL into Settings → Notifications, hit Test. The test message lands in the target channel within a couple of seconds. The format is Block Kit with a severity-colored bar, the rule name, the actual metric value, and a deep link back to the alert in MonPG. Click-through rates are higher than the old plaintext format we used to ship — color helps people triage.

Email

Comma-separated recipient list. Email comes from [email protected]; you can set the reply-to per channel if you want replies to land in a ticketing system instead of bouncing. HTML and plain-text both render reasonably; we test against Gmail/Outlook/Apple Mail.

PagerDuty

Get the integration key from your PD service (Events API v2). Paste it in. MonPG severities map to PD severities one-to-one (info/warning/critical → info/warning/critical), and recovery sends a resolve event so PD auto-closes the incident. Acks and resolves from the PagerDuty side propagate back to MonPG, so the rule history reflects what actually happened in your incident workflow.

Webhook

Generic HTTP POST to your endpoint with an HMAC signature so you can verify it's from us. The payload looks like this:

{
  "alert_id": "rh_abc123",
  "rule_id": "r_xyz",
  "rule_name": "Payments queue backlog",
  "server_id": 4,
  "server_name": "prod-db-1",
  "severity": "warning",
  "status": "firing",
  "metric_value": 137,
  "threshold": 100,
  "triggered_at": "2026-04-24T19:23:00Z",
  "details": { ... },
  "url": "https://app.monpg.app/alerts/rh_abc123"
}

This is the path most teams use to bridge into something we don't natively integrate with — Opsgenie, Microsoft Teams, a homegrown incident bot.

Routing

Each rule carries a list of channel IDs. We do not have a separate "routing tree" abstraction (we removed that under SD-022). The reason: most teams' routing rules ended up being one-liners — critical to PagerDuty, warning to Slack — and a routing tree is overkill for that. So pick channels per rule, on the rule's detail page.

If a channel breaks

Notifications go through a durable queue with exponential retry. A 502 from your webhook endpoint, a Slack rate-limit, a PagerDuty outage — all retried for up to 24 hours. Failed deliveries land on the Admin → Notification Queue page so you can see what's stuck and why. The biggest practical category is "Slack webhook URL was rotated and the old one is dead" — the queue tells you that immediately.