Alerting
Configure Slack, Discord, PagerDuty, and email alert channels with silence windows and delivery tuning.
Guides
Alerting
PreFlight routes alerts through the channels your team already uses — Slack, Discord, email, PagerDuty, OpsGenie, Microsoft Teams, and generic webhooks. This guide covers how to configure channels, understand delivery behavior, and tune noise.
Alerts fire when Monitoring or Sentinel crosses a failure threshold, when a Revenue Watch snapshot detects drift, or when a deploy gate blocks a release. They are event-driven from stored probe results — never from demo data.
Supported channels
| Channel | Transport | Best for |
|---|---|---|
| Slack | Bot token + channel ID | Team-wide visibility during launch |
| Discord | Webhook URL | Indie teams and community workspaces |
| Resend / Postmark / SendGrid | Async notification, audit trails | |
| PagerDuty | Events API v2 | On-call escalation for critical failures |
| OpsGenie | Alert API | On-call teams using Atlassian tooling |
| Microsoft Teams | Incoming webhook | Enterprise teams on Microsoft 365 |
| Generic webhook | HTTP POST | Custom integrations, Zapier, n8n, automation |
Configuration
Alert channels are configured per workspace at Settings → Alert channels. Each channel stores:
| Field | Purpose |
|---|---|
| Channel type | Slack, Discord, email, PagerDuty, OpsGenie, Teams, or webhook |
| Connection credentials | Bot tokens, webhook URLs, API keys (encrypted at rest) |
| Enabled state | Whether the channel is active for delivery |
| Notification preferences | Which event types trigger delivery on this channel |
- Open Settings → Alert channels in the workspace dashboard.
- Add a channel. Choose the type and provide credentials. Slack requires a bot token and channel ID; Discord needs just the webhook URL.
- Test the channel. Send a test alert to confirm delivery works before relying on it during a launch.
- Configure preferences. Choose which event types (monitoring failures, sentinel threshold, revenue drift, gate blocks) trigger on each channel.
When alerts fire
| Trigger | Source | Condition |
|---|---|---|
| Monitoring failure | 24-hour Monitoring session | Repeated health sample failures in the window |
| Sentinel threshold | 24/7 Sentinel | Consecutive failures cross the configured threshold |
| Revenue drift | Revenue Ledger Watch | Unresolved drift detected in scheduled snapshot |
| Deploy gate block | Deploy Gates | CI or Vercel receives a 409 blocked response |
| Integration failure | Provider probes | Critical provider becomes unreachable |
| Custom check failure | Custom Checks | HTTP assertion returns unexpected status |
Single failures are not alerts
A single failed Sentinel sample is noise. Alerts only fire after the failure threshold is crossed (default: 3 consecutive failures). This prevents alert fatigue from transient network issues.
Alert lifecycle
Probe fails → Failure counter increments → Threshold crossed → Alert created
→ Delivered to configured channels → Logged in Alerts dashboard
→ Issue resolved → Counter resets → Follow-up alert (optional)
Each delivery attempt is recorded in the Alerts dashboard (/dashboard/alerts) with:
- Delivery status (sent, failed, bounced, skipped)
- Channel and timestamp
- Source event and project context
- Error details if delivery failed
Silence windows
Use Silences to suppress alerts during planned maintenance, known provider outages, or while actively debugging:
| Field | Purpose |
|---|---|
| Start time | When suppression begins |
| End time | When suppression lifts (or "until manually cleared") |
| Scope | All alerts, specific project, or specific probe key |
| Reason | Human-readable note for the silence |
Silenced alerts are still recorded in the Flight Recorder — they just don't trigger channel delivery. This preserves the audit trail while preventing noise.
Tuning alert quality
| Problem | Fix |
|---|---|
| Too many alerts | Raise Sentinel failure threshold; lengthen cadence; use silence windows |
| Alerts too slow | Lower threshold; shorten Sentinel cadence; use faster cron schedule |
| Wrong channel fires | Check notification preferences per channel type |
| Alerts for known issues | Create a silence window scoped to the affected probe |
| No alerts at all | Verify channel is enabled, credentials work, and cron is running |
Channel-specific setup
Slack
- Create a Slack app with
chat:writepermission. - Install to your workspace and note the bot token (
xoxb-…). - Invite the bot to the target channel.
- Add the bot token and channel ID in PreFlight Settings → Alert channels.
Discord
- Open channel settings → Integrations → Webhooks.
- Create a new webhook and copy the URL.
- Paste the webhook URL in PreFlight Settings → Alert channels.
Email alerts use the transactional provider configured on your workspace (Resend, Postmark, or SendGrid). No additional channel-specific config needed beyond the workspace email settings.
PagerDuty
- Create an Events API v2 integration in PagerDuty.
- Copy the integration key (routing key).
- Add as a PagerDuty channel in PreFlight with the routing key.
Alerts map to PagerDuty severity levels based on probe status.
Viewing delivery history
The Alerts dashboard shows every delivery attempt with status:
| Status | Meaning |
|---|---|
sent | Successfully delivered to the channel |
failed | Delivery attempted but rejected (check credentials) |
bounced | Email bounced or channel unreachable |
skipped | Suppressed by silence window or notification preferences |
rate_limited | Too many alerts in the window; backed off |
Best practices
- Start with one channel. Validate delivery works on Slack or Discord before adding PagerDuty or email.
- Separate urgency levels. Use PagerDuty for production Sentinel alerts; Slack for informational monitoring events.
- Test before launch. Send test alerts to every channel before your launch window opens.
- Silence during maintenance. Create silence windows before planned deploys to avoid false alarms.
- Review weekly. Check the Alerts dashboard for failed deliveries and tune thresholds based on actual noise.