Reference

Alerts & Integrations

Pillar routes incidents to notification destinations by event class, not raw severity threshold, so a destination can be scoped to exactly the kinds of incidents it should page for.

Connect and test a destination

In Settings → Alerts & Integrations, a Facility Admin or Organization Admin adds a destination and supplies the provider’s required endpoint, credentials, or recipients.
Use the test action and confirm receipt in the destination service. Save the desired event-class routing and make sure the destination is enabled.
Inspect the last-delivery result after a real event. A saved configuration or a successful test does not guarantee later delivery.

Incident messages can include hostnames, device identifiers, and operational context. Route them only to approved recipients. If delivery fails, inspect credentials, endpoint availability, and provider restrictions; continue monitoring incidents in Pillar.

1.Event Classes

A destination is notified for an incident if it is routed for any class the incident matches. Severity classes always apply; topical classes layer on top.

Event class	Label	Matches
critical_incidents	Critical incidents	Any incident opened or escalated at critical severity.
warning_incidents	Warning incidents	Any incident opened or escalated at warning severity.
capacity_forecasts	Capacity forecasts	Capacity pressure and rapid ingest.
maintenance_forecasts	Maintenance forecasts	Scrub/resilver collisions with operating hours.
posture_exceptions	Posture exceptions	Security posture drift and component health.

2.Destination Kinds

Kind	Label	Masked secret field(s)
slack	Slack	webhookUrl
discord	Discord	webhookUrl
pagerduty	PagerDuty	routingKey
opsgenie	Opsgenie	apiKey
email	Email	— (no secret fields)
webhook	Webhook	signingSecret

Saved integration secret fields are masked in read responses — see Settings.

3.Delivery Rules

Opened / escalated: delivery is attempted to each enabled destination routed to at least one matching event class.
Resolved: resolution routing uses destinations with a recorded successful send for that incident, rather than only the current routing grid. Destination availability and delivery errors can still prevent receipt.

4.Webhook Delivery Contract

For building your own receiver against the generic webhook destination:

text

POST <your-endpoint>
Content-Type: application/json
X-Pillar-Signature: sha256=<hmac-sha256 of the raw body, using your signing secret>
X-Pillar-Timestamp: <sentAt, ISO 8601>

JSON body:

json

{
  "event": "alert.triggered",
  "incident": {
    "id": "...", "studioId": "...", "nodeId": "...", "diskId": "...",
    "alertType": "...", "severity": "critical", "title": "...", "message": "...",
    "hostname": "...", "deviceName": "...", "metadata": {}
  },
  "facility": "...",
  "sentAt": "2026-09-12T15:00:00Z"
}

The signature is an HMAC-SHA256 of the raw JSON body using your configured signing secret, hex-encoded and prefixed sha256=.
The webhook URL is re-validated immediately before every send (not just at configuration time) to shrink the DNS-rebinding window between approval and connection.
Delivery times out after 10 seconds; a timeout or non-2xx response is recorded as a failed delivery, visible in the destination's last-delivery status in Settings.