> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corbado.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Deliver Alert Notifications
> Send Corbado Observe alerts by email, signed webhooks or PagerDuty, with severity floors and delivery hours per contact point.
Every alert rule notifies one contact point. A contact point is a named destination, such as "Auth on-call", that bundles one or more integrations: email, webhook and PagerDuty. Several rules can share a contact point, so changing a recipient happens in one place. Manage contact points in [**Observe → Alerting → Contact points**](https://app.corbado.com/observe/alerting/contact-points).
## 1. What a notification contains
Observe notifies when an alert starts firing, escalates to a higher severity, resolves or loses its data. A notification is sent once per state change. All alerts of one rule that change in the same evaluation are sent together in one message.
Each notification names the rule, the severity, the affected groups with their values and thresholds, the evaluated window and a link to the alert in the console.
## 2. Integrations
| Integration | Use for | Setup |
| - | - | - |
| **Email** | Team inboxes and individual recipients | Up to 10 addresses per integration |
| **Webhook** | Your own monitoring stack, chat tools, incident tooling | HTTPS URL, optional custom headers, signed requests |
| **PagerDuty** | On-call escalation | Events API v2 integration key, US or EU region |
| **Custom integration** | An alerting or incident service not listed here | Included in every enterprise deployment: Corbado connects your service |
Each integration has its own **severity floor**: everything, info and above, warning and above, or critical only. A floor suppresses less severe notifications. Resolved notifications bypass the severity floor but remain subject to delivery hours and whether the integration is paused.
Each integration can also be **paused** without deleting it. Use the test action on a contact point before relying on it. A successful test confirms the delivery path. Rule thresholds are checked in the rule's history.
Failed deliveries are retried up to three times within 30 seconds. Every attempt, including failures, is recorded in the rule's notification history.
## 3. Webhooks
Webhooks follow the [Standard Webhooks](https://www.standardwebhooks.com/) specification. Every request is a JSON `POST` with these headers:
* **`webhook-id`:** a unique message ID, stable across retries. Use it to deduplicate.
* **`webhook-timestamp`:** the send time in Unix seconds.
* **`webhook-signature`:** an HMAC-SHA256 signature over `id.timestamp.body`, created with the signing secret shown when you create the integration.
Verify the signature with any Standard Webhooks library before processing a request. You can add up to 10 custom headers, for example a routing key for your gateway. Headers starting with `webhook-` and transport headers are reserved.
```json theme={null}
{
"type": "alert.firing",
"timestamp": "2026-10-05T14:21:00Z",
"version": "1",
"data": {
"project": { "id": "pro-1234567890", "name": "Production" },
"rule": {
"id": "aru-42",
"name": "Login volume drop",
"type": "flow_volume",
"unit": "percent",
"url": "https://app.corbado.com/..."
},
"severity": "critical",
"alerts": [
{
"id": "ain-7",
"labels": { "application": "app-123" },
"severity": "critical",
"value": 18.4,
"threshold": { "operator": "below", "value": 25 },
"url": "https://app.corbado.com/..."
}
]
}
}
```
**Event types:** `alert.firing`, `alert.escalated`, `alert.resolved`, `alert.no_data` and `alert.test`. Values are numeric. Read `rule.unit` to tell percentages from counts.
## 4. PagerDuty
Create an Events API v2 integration on your PagerDuty service and paste its integration key. Each alert opens its own PagerDuty alert and resolves it automatically when the Observe alert recovers. A test notification opens real PagerDuty alerts with example data, so run it against a test service or inform your on-call team first.
## 5. Delivery hours
Delivery hours limit when a contact point notifies. Set a timezone and up to 10 weekly time ranges in 15-minute steps, for example Monday to Friday from 08:00 to 18:00 for a team without on-call duty.
Outside delivery hours, alerts are still evaluated and shown in the console, but notifications are not sent and not queued for later. Use a separate contact point without delivery hours for anything that must reach someone at night, and route only critical rules to it.
Delivery hours belong to the team that receives an alert. To stop judging traffic during quiet local hours, for example nights per market, use [business hours](/corbado-observe/alerting/alert-rules#10-business-hours) on the rule instead.
## 6. Manage alerting through the API
Rules, contact points, alerts, evaluations, transitions and notifications are available through the [Observe API](/api-reference/observe/overview). Use an API key with `observe:alerts:read` to pull alert history into your own dashboards, and `observe:alerts:write` to manage rules and contact points as code.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.