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 Uptime Monitoring crosses a failure threshold, when a Payment Sync snapshot detects drift, or when a release rule 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 |
| Email | 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, Uptime Monitoring threshold, payment 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 |
| Uptime Monitoring threshold | Continuous Uptime Monitoring | Consecutive failures cross the configured threshold |
| payment drift | Payment Sync | Unresolved drift detected in scheduled snapshot |
| release rule block | Release Rules | 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 |
A single failed Uptime Monitoring 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 Event Timeline — they just don't trigger channel delivery. This preserves the audit trail while preventing noise.
Tuning alert quality
| Problem | Fix |
| --- | --- |
| Too many alerts | Raise Uptime Monitoring failure threshold; lengthen cadence; use silence windows |
| Alerts too slow | Lower threshold; shorten Uptime Monitoring 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:write permission.
- 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
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 Uptime Monitoring 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.
<RelatedLinks
links={[
{ href: "/docs/guides/monitoring-and-sentinel", title: "Uptime Monitoring", description: "The watchdogs that generate alert-worthy events." },
{ href: "/docs/guides/command-center", title: "Command Center", description: "Where Alerts sits in the dashboard layout." },
{ href: "/docs/guides/deploy-gates", title: "Release Rules", description: "Gate blocks that can also trigger alerts." },
{ href: "/docs/guides/revenue-watch", title: "Payment Sync", description: "payment drift alerts." },
]}
/>
